I have a subclass which inherits the properties and methods of a super class. However, I want this subclass to only inherit some of the properties from the superclass, not all of them.
In OO programming, is this bad practice? I have noticed that it is impossible to do in ES6 JavaScript.
This is not possible in OOP
If you define B as subclass of A, then B inherits all the properties and methods from A.
There are some exceptions:
private members of A will not be accessible in B (BTW the code will be there)
initializers/constructors are not always automatically inherited, here the rules depend on the language you are using
Related
I have a public abstract class which I want other classes in the module to extend, but I do not want to to be extendible externally.
I am aware I could make it sealed, but it has many subclasses and would be cumbersome to have them all in the same file. How can this be achieved?
You can define its constructor as internal. Subclasses must call the superclass' constructor, so only files that can see that constructor will be able to subclass your class.
You can make it sealed, but declare just one internal (and not sealed) subclass in the same file. Then other classes in the module can see and extend the internal subclass, and so your original class.
Note that classes which extend subclasses of a sealed class (indirect inheritors) can be placed anywhere, not necessarily in the same file.
EDIT: the drawback is that the extending classes must also be internal (or even less visible). Louis Wasserman's solution avoids this and is simpler.
From Programming Language Pragmatics, by Scott
A derived class D has all the members—data and subroutines—of its base
class C. As long as D does not hide any of the publicly visible
members of C, it makes sense to allow an object of class D to be used
in any context that expects an object of class C: anything we might
want to do to an object of class C we can also do to an object of
class D. In other words, a derived class that does not hide any
publicly visible members of its base class is a subtype of that base
class.
If D overrides a public method of C,
does the overriding method of D hide the overridden method of C, and
does the overriding disqualifies D from being a subtype of C?
What can make a derived class hide a public method of a base class?
Thanks.
does the overriding method of D hide the overridden method of C
No, overriding is different from hiding, because you are providing a replacement implementation instead of an existing one, not just taking away an implementation without any replacement.
Most object-oriented languages disallow hiding of methods that are designated for overriding (virtual of C++, abstract and virtual of C#). Some languages do not allow hiding at all (Java). This is done precisely to ensure that inheriting D from C models "is-a" relationship.
does the overriding disqualifies D from being a subtype of C?
No, it does not.
does the overriding disqualifies D from being a subtype of C?
It depends. If the method in D breaks the contract that the method in C defines, then yes it would disqualify D from being a subtype. If the D method supports the same contract then it doesn't.
I suggest you read up on the Liskov Substitution Principle. Here is the original article she wrote in 1994. It's quite readable.
http://www.csnell.net/computerscience/Liskov_subtypes.pdf
I understand that Abstract Classes are classes that contain declared methods that do not all necessarily have a specified implementation because the code would have to be declared in the child class instead but Im finding it difficult to understand the OOP concept behind the introduction of Interfaces.
What are the architectural and principle differences between interfaces and abstract classes if the abstract class has no defined methods and states (Aside from the fact that abstract classes can have constructors)?
In addition, why should anyone use abstract classes and interfaces in the first place? I understand that it adds restrictions to your code not allowing people to defined subclasses without specified methods but the code would work in the exact same way if the non implemented declared methods were not present in the interface and abstract class. So what is the implied benefit of writing methods with no implementation only to implement it later in the subclass?
I have seen many posts on Interface vs Abstract Classes but im interested in the principle differences between the two, not their functional differences.
Coming back to my own question after a year, I have discovered the answer that I wanted.
A class, regardless of being abstract or not, always tries to define/design what entities look like from their behaviour to their states. In the case of an abstract class, we are modelling an idea/entity that we do not want to be instantiated during run time. Example, if we had an app about dogs and cats, we may want to define what an animal is and then extend this idea to define what a dog/cat is by extending our base animal class. An animal object will never be instantiated but a dog/cat will.
An interface on the other hand are a set of methods that represents some form of interactions to be expected from any class. As long as a class implements an interface, you know what methods to expect from it. Thus, you can have two entities (classes) that do not relate to one another that implement the same interface. Example, a dog and person class may both implement a 'digest' interface. This means that they are all able to digest food as we have explicitly stated what functions to expect in the interface to enable food digestion behaviour. Obviously the details of the implementation differs thus the functions defined in the interface are outlined in the classes implementing them.
I have classA and ClassA inherit ClassX and access methods of classX. How can I also access the methiod of ClassY with inheritance because multiple inheritance is not possible. I dont want to create another other composition class for this.I want to use same classA for multiple inheritance.
There is no multiple inheritance. The only way to achieve this is by merging the two class heirarchies. Either by having ClassX inherit ClassY or ClassY inherit ClassX (then ClassA inherits the child class X or Y).
If the two classes do not by design fit into the same hierarchy, you might want to reconsider your design and the reasons why you do not want to use composition.
Like Objective-C, Swift does not have multiple inheritance. Swift uses protocols and categories to give you the same sort of ability. You can define a protocol that defines a set of methods, and then you can add support for that protocol to multiple classes. You can often build support for a protocol into a category and then that category to your classes as needed.
As said before, multiple inheritance is not supported by the language (neither ObjC nor Swift). If you need to inherit methods/properties from multiple classes, you will need to use composition. Alternatively, what the language does allow you to do is to have a class conform to multiple protocols, which may or may not be a solution to the problem you are trying to solve.
I have come across very few cases where I thought that I really needed to have multiple inheritance, and even for those cases, they were typically resolved by employing an appropriate code design pattern (thinking about something like the Gang of Four design patterns). In essence, you want to abstract your code in such a way so that multiple inheritance is not a requirement anymore.
I have a protocol P
#protocol P<NSObject>
{
-(void)foo;
#optional
-(void)bar;
}
And I have bunch of classes (let say a dozen). All of these classes implement protocol P. About half of them implement method bar and all of bar implementations are exactly the same.
What is the best way to share implementation of bar?
Obvious ideas:
1) Create some base class which will implement method bar and let other classes to inherit it.
It's simple to implement. However, I am not big fan of this idea. I prefer class hierarchy to represent entity generalization/specification rather than code reuse.
2) Create a helper and call it from all of classes which needs to implement bar method
Ok. It works. However, if implementation of bar is small (couple of lines in my case) then we will have more overhead (helper class and calling it from each class) than the code itself.
Is there any other (better) methods?
Here are a few ways to share method implementations between classes:
Inheritance. You can make all your classes inherit from a common base class that implements the shared methods. But you can't do this if, for example, you need class A to inherit from UIViewController and class B to inherit from NSManagedObject.
Create a category on a base class shared by all your classes. For example, NSObject is the base class of (virtually) every other class. You can create a category on NSObject to add methods that all classes inherit. If you do this, you should put a prefix your method names to ensure that they won't conflict with other names. E.g. use ronin_foo and ronin_bar instead of just foo and bar.
Create a file containing the method implementations, not surrounded by an #implementation block. Then #include this file in the middle of the #implementation block of each class that needs the methods. Note that the compiler will generate a copy of the machine code for each class, so this could make your program substantially bigger.
At runtime, use the Objective-C runtime API to copy methods from one class to another. You will need to read the Objective-C Runtime Programming Guide and parts of the Objective-C Runtime Reference. You will probably also need to google up some examples.