I already read the documentation about the new modifiers "open" and "fileprivate". But there are two things that I don't understand:
Why is it not possible to declare protocols or extensions also as "open"? And does it mean that it's not possible to use these things outside a module?
If I don't want to build my classes for a module but an common app, should I declare my classes and methods as "open" anyway or is it good practice to keep them only "public"?
As this answer says:
An open class is accessible and subclassable outside of the defining module. An open class member is accessible and overridable outside of the defining module.
A public class is accessible but not subclassable outside of the defining module. A public class member is accessible but not overridable outside of the defining module.
I think the answer to your first question, is that you can't override or subclass a protocol or extension. Thus, there is no use for such things to be open because public already makes them accessible outside of a module.
For your second question, I would say that you should only declare your own classes as open if you plan on overriding or subclassing. Otherwise you are allowing unnecessary access to these items. Most of the time public should suit your needs.
Edit:
As #Alex points out, I don't think there are many downsides to allowing this "extra access". The only thing I can think of is if you just wanted to protect your classes from your future self, but that may or may not be applicable. Thus, if this is not the case, there shouldn't be much harm in setting them as open by default.
open is for another module, for example in we use it in unit test or in cocoa pods, you can inherit from a pod (if it's: open class somePod {...}) or override some function (if it's: open func someFunctionInPod{...}) in your project.
Related
Say I have something like this:
#Module
internal class SeenModule {
#Provides
fun parameter() = Parameter()
#Provides
fun actualThingINeedToInject(parameter: Parameter) = ActualThing(parameter)
}
However, this module only really needs to provide an ActualThing object - in other words, the Parameter is only there because the very own module needs it. I don't want it to be part of the set of dependencies that can be retrieved outside of this module.
The way I'm currently doing this is by defining a custom scope as private and then marking the methods that provide dependencies which shouldn't leave the module with this scope, as well as those in the module where the provided dependencies should be injected, of course. This is a bit annoying because it prevents me from using other scopes in these methods and requires a lot of additional annotating all over the place. What is the proper way to achieve this?
Dagger doesn't really offer "private bindings" in the sense you're asking for, where Parameter would not be injectable from anywhere else. I also advise against using scope annotations for visibility, in part because the Component itself would need to be annotated with that scope annotation, so the scope annotation would simply slightly increase the hassle needed to improperly consume Parameter (and the hassle needed to create a Component that properly consumes Parameter).
I'd offer one of these three alternatives:
Reduce the visibility of Parameter as a class. If Parameter is package-private, you won't be able to refer to it from outside of that Java package, giving you the encapsulation you want.
Use "Subcomponents for Encapsulation", in which you create a subcomponent, install your Parameter (and any related bindings) in a Module bound on the subcomponent, and expose only your ActualThing on the subcomponent's interface. Your subcomponent will be injectable, but your Parameter is not; you can also write a #Provides method that returns your ActualThing from your subcomponent instance.
Grin and bear it, and just document that Parameter is an implementation detail that should not be accessed outside of certain packages. If you are providing objects to external teams who access ActualThing through your Component interface, you can simply decline to put Parameter on your public interface; if you are providing objects to internal teams they will likely have access to change your Dagger structure or access modifiers anyway. You might also ask yourself why Parameter would be useful for another team to consume, and document it as an API if there is a business reason for injecting it.
The ObjectiveC.swift file from the standard library contains the following few lines of code around line 228:
extension NSObject : Equatable, Hashable {
/// ...
open var hashValue: Int {
return hash
}
}
What does open var mean in this context, or what is the open keyword in general?
open is a new access level in Swift 3, introduced with the implementation
of
SE-0117 Allow distinguishing between public access and public overridability
It is available with the Swift 3 snapshot from August 7, 2016,
and with Xcode 8 beta 6.
In short:
An open class is accessible and subclassable outside of the
defining module. An open class member is accessible and
overridable outside of the defining module.
A public class is accessible but not subclassable outside of the
defining module. A public class member is accessible but
not overridable outside of the defining module.
So open is what public used to be in previous
Swift releases and the access of public has been restricted.
Or, as Chris Lattner puts it in
SE-0177: Allow distinguishing between public access and public overridability:
“open” is now simply “more public than public”, providing a very simple and clean model.
In your example, open var hashValue is a property which is accessible and can be overridden in NSObject subclasses.
For more examples and details, have a look at SE-0117.
Read open as
open for inheritance in other modules
I repeat open for inheritance in other modules.
So an open class is open for subclassing in other modules that include the defining module. Open vars and functions are open for overriding in other modules. Its the least restrictive access level. It is as good as public access except that something that is public is closed for inheritance in other modules.
From Apple Docs:
Open access applies only to classes and class members, and it differs from public access as follows:
Classes with public access, or any more restrictive access level, can
be subclassed only within the module where they’re defined.
Class members with public access, or any more restrictive access level, can
be overridden by subclasses only within the module where they’re
defined.
Open classes can be subclassed within the module where they’re defined, and within any module that imports the module where
they’re defined.
Open class members can be overridden by subclasses
within the module where they’re defined, and within any module that
imports the module where they’re defined.
Open is an access level, was introduced to impose limitations on class inheritance on Swift.
This means that the open access level can only be applied to classes and class members.
In Classes
An open class can be subclassed in the module it is defined in and in modules that import the module in which the class is defined.
In Class members
The same applies to class members. An open method can be overridden by subclasses in the module it is defined in and in modules that import the module in which the method is defined.
THE NEED FOR THIS UPDATE
Some classes of libraries and frameworks are not designed to be subclassed and doing so may result in unexpected behavior. Native Apple library also won't allow overriding the same methods and classes,
So after this addition they will apply public and private access levels accordingly.
For more details have look at Apple Documentation on Access Control
open come to play when dealing with multiple modules.
open class is accessible and subclassable outside of the defining module. An open class member is accessible and overridable outside of the defining module.
open is only for another module for example: cocoa pods, or unit test, we can inherit or override
In c# we have the protected accessor which allows class members to be visible on inherited clases but not for the rest.
In Swift this doesn't exist so I wonder what's a correct approach for something like this:
I want to have a variable (internal behavior) and and a public method using this variable on a base class. This variable will be used also on inherited clases.
Options I see
Forget about base class and implement variable and methods everywhere I need it. WRONG, duplicated code
Implement inheritance by composition. I'd create a class containing common methods and this will be used by composition instead of inheritance. LESS WRONG but still repeating code that could be avoided with inheritance
Implement inheritance and make variable internal on base class. WRONG since exposes things without any justification except allowing visibility on inherited clases.
Implementation Details for Base Class
I want to have a NSOperationQueue instance and and a public method to cancel queued operations. I add new operations to this queue from inherited classes.
In Swift the correct answer is almost always protocols and extensions. It is almost never inheritance. Sometimes Cocoa stands in our way, because there are classes in Cocoa more often than protocols, but the goal is almost always protocols and extensions. Subclassing is our last choice.
Your particular case is confusing because NSOperationQueue already has a public method to cancel queued operations (cancelAllOperations). If you want to protect the queue from outside access (prevent callers from using addOperation directly for instance), then you should put the queue inside another type (i.e. composition), and forward what you want to the queue. More details on the specific problem you're solving would allow us to help suggest other Swift-like solutions.
If in the end you need something that looks like protected or friend, the correct solution is private. Put your subclass or your friend in the same file with the target, and mark the private thing private. Alternately, put the things that need to work together in a framework, and mark the attribute internal. The Swift Blog provides a good explanation of why this is an intentional choice.
Are there any risks involved with using the protected member access specifier instead of the private member access specifier?
You have not specified which lamguage but, I assume in OO language like java, a protected member is "visible" to child classes. Latter can use them and may break if you happen to change protected members later due to evolution of your class or change in requirements. No such risk in case of private members. A child class can extend the protected members and make it exposed to the outside (public) world.
This answer assumes you are using a language like java:
private members can only be seen by its own class (and inner classes). This is the safest field visibility since it is hidden from all outsiders. Since it's completely hidden, you are free to change the implementation details or even get rid of the field completely later on.
protected members can not only be seen by all subclasses but also from ALL classes that are in the same package. This makes it much harder to later change the field because more classes might be referencing it.
Similar question but not quite the same thing
I was thinking that with extension methods in the same namespace as the interface you could get a similar effect to multiple inheritance in that you don't need to have duplicate code implementing the same interface the same way in 10 different classes.
What are some of the downsides of doing this? I think the pros are pretty obvious, it's the cons that usually come back to bite you later on.
One of the cons I see is that the extension methods can't be virtual, so you need to be sure that you actually do want them implemented the same way for every instance.
The problem that I see with building interface capability via extension methods is that you are no longer actually implementing the interface and so can't use the object as the interface type.
Say I have a method that takes an object of type IBar. If I implement the IBar interface on class Foo via extension methods, then Foo doesn't derive from IBar and can't be used interchangeably with it (Liskov Substitution principle). Sure, I get the behavior that I want added to Foo, but I lose the most important aspect of creating interfaces in the first place -- being able to define an abstract contract that can be implemented in a variety of ways by various classes so that dependent classes need not know about concrete implementations.
If I needed multiple inheritance (and so far I've lived without it) badly enough, I think I'd use composition instead to minimize the amount of code duplication.
A decent way to think about this is that instance methods are something done by the object, while extension methods are something done to the object. I am fairly certain the Framework Design Guidelines say you should implement an instance method whenever possible.
An interface declares "I care about using this functionality, but not how it is accomplished." That leaves implementers the freedom to choose the how. It decouples the intent, a public API, from the mechanism, a class with concrete code.
As this is the main benefit of interfaces, implementing them entirely as extension methods seems to defeat their purpose. Even IEnumerable<T> has an instance method.
Edit: Also, objects are meant to act on the data they contain. Extension methods can only see an object's public API (as they are just static methods); you would have to expose all of an object's state to make it work (an OO no-no).