The process in which the newly created class uses elements of a more general class of already existing is inheritance, but is this also apply to the polymorphism?. I can't find in the internet an satisfying answer.
Inheritance is derived from the overall concept of polymorphism. Inheritance would be more specifically a type of Ad hoc polymorphism. The concept of an object oriented language in general is to allow features such as inheritance and abstraction. So inheritance allows the specialization of classes in say a hierarchical manner so then subclasses may inherit from a parent or more "general class", while Polymorphism allows you to use an object without knowing its exact type such as calling an inherited or virtual method and the language being able to get the correct method from many derivations or implementations of such method.
No, Polymorphism is where two or more classes that either implement the same interface or extend the same parent can be substituted for each other.
An example is how a List and a HashTable are both Collections and may be substituted for each other when the object is defined as the general type (Collection)
The benefits of using composition over inheritance are quite well known;
What are the cases in which the opposite is preferable?
Practically, I can see the advantage of forcing a base constructor, but I would like to know other people's opinion about other cases/domains.
I believe the famous recommendation of "favor composition over inheritance" was coined in the GoF Design Patterns book.
It says (p.20):
Favor object composition over class inheritance.
Ideally, you shouldn't have to create new components to achieve reuse.
You should be able to get all the functionality you need just by
assembling existing components through object composition. But this is
rarely the case, because the set of available components is never
quite rich enough in practice. Reuse by inheritance makes it easier to
make new components that can be composed with old ones. Inheritance
and object composition thus work together.
Nevertheless, our experience is that designers overuse inheritance as
a reuse technique, and designs are often made more reusable (and
simpler) by depending more on object composition. You'll see object
composition applied again and again in the design patterns.
Notice that this statement refers to class inheritance, and must be distinguished from interface inheritance which is fine.
Dynamism
Both are ways to achieve reusability, but the advantage of composition over inheritance is dynamism. Since the composition can be changed dynamically at runtime this represents a great advantage, whereas inheritance is statically defined at compile time.
Encapsulation
Also, composition is based on using the public interfaces of the composed objects, therefore objects respect each other's public interfaces and therefore this fosters encapsulation. On the other hand, inheritance breaks encapsulation since child components typically consume a protected interface from the parent. It is a well known problem that changes in the parent class can break the child classes, the famous base class problem. Also in inheritance parent classes define the physical representation of subclasses, therefore child clases depend on parent classes to evolve.
Cohesion
Another advantage of composition is that it keeps classes focused on one task and this foster cohesion as well.
Liabilities
Evidently a problem with composition is that you will have more objects and fewer classes. That makes a little more difficult to visualize your design and how it achieves its goals. When debugging code it is harder to know what is going on unless you know what exact instance of a given composite is currently being used by an object. So composition makes designs a bit harder to understand in my opinion.
Since the advantages of composition are multiple that's why it is suggested to favor it over inheritance, but that does not mean inheritance is always bad. You can achieve a great deal when inheritance is properly used.
Interesting References
I would suggest a study of GoF Design Patterns to see good examples of both types of reusability, for instance a Strategy Pattern that uses composition vs a Template Method that uses inheritance.
Most of the patterns make a great use of interface inheritance and then object composition to achieve their goals and only a few use class inheritance as a reusability mechanism.
If you want to delve more the book Holub on Patterns, on chapter 2 has a section called Why extends is Evil that delve much more on the liabilities of class inheritance.
The book mentions three specific aspects
Losing Flexibility: The first problem is that explicit use of a concrete-class name locks you into a specific implementation, making
down-the-line changes unnecessarily difficult.
Coupling: A more important problem with implementation inheritance is coupling, the undesirable reliance of one part of a
program on another part. Global variables are the classic example of
why strong coupling is bad. If you change the type of a global
variable, for example, all the code that uses that variable—that is
coupled to the variable—can be affected, so all this code must be
examined, modified, and retested. Moreover, all the methods that use
the variable are coupled to each other through the variable. That is,
one method may incorrectly affect the behavior of another method
simply by changing the variable’s value at an awkward time. This
problem is particularly hideous in multithreaded programs.
Fragile-Base-Class Problem: In an implementation-inheritance system (one that uses extends), the derived classes are tightly
coupled to the base classes, and this close connection is undesirable.
Designers have applied the moniker “the fragile-base-class problem” to
describe this behavior. Base classes are considered “fragile” because
you can modify a base class in a seemingly safe way, but this new
behavior, when inherited by the derived classes, may cause the derived
classes to malfunction.
The only advantage of inheritance over composition that I can think of is that it can potentially save you from a lot of boiler plate method delegation.
If you truly have an is-a relationship and you simply want all the methods from a base class in your subclass, then inheritance gives you all those methods for free.
It's a complete debatable or argumentation question and broad as well.
AFAIK, when we talk about containership (or) something containing another thing we go for Composition; i.e, An entity contains another entity; which also gives a HAS A relationship. Example: EntityA has a EntityB.
See Decorator design pattern, which is based on the concept of Composition.
But when we talk about Inheritance we talk about IS A relationship. i.e, EntityA Is A EntityB (or) EntityA Is type of a EntityB
One special case when I find inheritance the best solution is when I use a runtime-generated class that need additional methods. For example (in C#):
public abstract class Rule{
/* properties here */
public Authorization Authorization { get; set; }
public abstract bool IsValid(dynamic request, User currentUser);
}
The generated template:
public class Generated_1Rule : Rule{
public override bool IsValid(dynamic request, User currentUser){
// the user script is here
}
}
Example of user script:
return Authorization.IsAuthorized("Module_ID_001", currentUser);
The benefit is that you can add functionality to the generated script “compiled-ly”, and it’s less breaking than inheriting from interface / composition since it is compiled.
I usually come across some design problems in which I have the choice to either specialize a class by inheriting it by a sub class, or specialize the class by defining an attribute for it that classifies it. For example, for the collection of components of a car, we can either define classes (e.g. Wheel, Tire, Door ... etc), or we can define a single class "CarComponent" which have an attribute called "Type" that takes a value from an enumeration that list the different types of car components.
How can we compare those two approaches, and what design patterns would recommend each of them?
Thanks.
Inheritance is about changing behaviour. If you're not changing behaviour, you have no need for a subclass. Inheritance should never be about creating a class for each noun, no matter how nice it looks.
What behaviour does CarComponent have in the context of the problem?
Then what different behaviours do Wheel, Tire, and Door have?
If they behave differently, they may be subclasses of CarComponent (but not necessarily, see below). If they don't behave differently, they're just a type.
If they do behave differently, can you accomplish the same thing with Composition? Can you move the behaviours into a Strategy?
"Prefer composition over inheritance" isn't just a slogan, it's a good idea.
I know that interfaces cannot contain method body and we can implement in another classes and can write our custom logic. But the same thing can also implement by using inheritance with classes. Then why interfaces come into picture. If we want to override any method definition we can do in inheritance of classes and can write our custom code. What is the exact purpose of interfaces?
One reason is that a class may implement multiple interfaces but only derive from a single class.
Another is, that hierarchically totally unrelated classes may implement the same interface. In statically typed languages without interfaces, one can often observe very deep inheritance hierarchies, created only because they could not simply implement an interface and had to force unrelated classes to derive. This often tends to violate the "Is a" - principle of inheritance. Such implementations also tend to drag around unused code, just because it is needed further down the inheritance tree.
tl;dr - it can be done but the results are often ugly and unmaintainable
Interfaces - The object can do this.
Class - This is how the object does this.
Also interfaces can be used to avoid the diamond problem
This is more of a subjective question, so I'm going to preemptively mark it as community wiki.
Basically, I've found that in most of my code, there are many classes, many of which use each other, but few of which are directly related to each other. I look back at my college days, and think of the traditional class Cat : Animal type examples, where you have huge inheritance trees, but I see none of this in my code. My class diagrams look like giant spiderwebs, not like nice pretty trees.
I feel I've done a good job of separating information logically, and recently I've done a good job of isolating dependencies between classes via DI/IoC techniques, but I'm worried I might be missing something. I do tend to clump behavior in interfaces, but I simply don't subclass.
I can easily understand subclassing in terms of the traditional examples such as class Dog : Animal or class Employee : Person, but I simply don't have anything that obvious I'm dealing with. And things are rarely as clear-cut as class Label : Control. But when it comes to actually modeling real entities in my code as a hierarchy, I have no clue where to begin.
So, I guess my questions boil down to this:
Is it ok to simply not subclass or inherit? Should I be concerned at all?
What are some strategies you have to determine objects that could benefit from inheritance?
Is it acceptable to always inherit based on behavior (interfaces) rather than the actual type?
Inheritance should always represent an "is-a" relationship. You should be able to say "A is a B" if A derives from B. If not, prefer composition. It's perfectly fine to not subclass when it is not necessary.
For example, saying that FileOpenDialog "is-a" Window makes sense, but saying that an Engine "is-a" Car is nonsense. In that case, an instance of Engine inside a Car instance is more appropriate (It can be said that Car "is-implemented-in-terms-of" Engine).
For a good discussion of inheritance, see Part 1 and Part 2 of "Uses and Abuses of Inheritance" on gotw.ca.
As long as you do not miss the clear cut 'is a' relationships, it's ok and in fact, it's best not to inherit, but to use composition.
is-a is the litmus test. if (Is X a Y?) then class X : Y { } else class X { Y myY; } or class Y { X myX; }
Using interfaces, that is, inheriting behavior, is a very neat way to structure the code via adding only the needed behavior and no other. The tricky part is defining those interfaces well.
No technology or pattern should be used for its own sake. You obviously work in a domain where classes tend to not benefit from inheritance, so you shouldn't use inheritance.
You've used DI to keep things neat and clean. You separated the concerns of your classes. Those are all good things. Don't try and force inheritance if you don't really need it.
An interesting follow-up to this question would be: Which programming domains do tend to make good use of inheritance? (UI and db frameworks have already been mentioned and are great examples. Any others?)
I also hate the Dog -> Mammal -> Animal examples, precisely because they do not occur in real life.
I use very little subclassing, because it tightly couples the subclass to the superclass and makes your code really hard to read. Sometimes implementation inheritance is useful (e.g. PostgreSQLDatabaseImpl and MySQLDatabaseImpl extend AbstractSQLDatabase), but most of the time it just makes a mess of things. Most of the time I see subclasses the concept has been misused and either interfaces or a property should be used.
Interfaces, however, are great and you should use those.
Generally, favour composition over inheritance. Inheritance tends to break encapsulation. e.g. If a class depends on a method of a super class and the super class changes the implementation of that method in some release, the subclass may break.
At times when you are designing a framework, you will have to design classes to be inherited. If you want to use inheritance, you will have to document and design for it carefully. e.g. Not calling any instance methods (that could be overridden by your subclasses) in the constructor. Also if its a genuine 'is-a' relationship, inheritance is useful but is more robust if used within a package.
See Effective Java (Item 14, and 15). It gives a great argument for why you should favour composition over inheritance. It talks about inheritance and encapsulation in general (with java examples). So its a good resource even if you are not using java.
So to answer your 3 questions:
Is it ok to simply not subclass or inherit? Should I be concerned at all?
Ans: Ask yourself the question is it a truly "is-a" relationship? Is decoration possible? Go for decoration
// A collection decorator that is-a collection with
public class MyCustomCollection implements java.util.Collection {
private Collection delegate;
// decorate methods with custom code
}
What are some strategies you have to determine objects that could benefit from inheritance?
Ans: Usually when you are writing a framework, you may want to provide certain interfaces and "base" classes specifically designed for inheritance.
Is it acceptable to always inherit based on behavior (interfaces) rather than the actual type?
Ans: Mostly yes, but you'd be better off if the super class is designed for inheritance and/or under your control. Or else go for composition.
IMHO, you should never do #3, unless you're building an abstract base class specifically for that purpose, and its name makes it clear what its purpose is:
class DataProviderBase {...}
class SqlDataProvider : DataProviderBase {...}
class DB2DataProvider : DataProviderBase {...}
class AccountDataProvider : SqlDataProvider {...}
class OrderDataProvider : SqlDataProvider {...}
class ShippingDataProvider : DB2DataProvider {...}
etc.
Also following this type of model, sometimes if you provide an interface (IDataProvider) it's good to also provide a base class (DataProviderBase) that future consumers can use to conveniently access logic that's common to all/most DataProviders in your application model.
As a general rule, though, I only use inheritance if I have a true "is-a" relationship, or if it will improve the overall design for me to create an "is-a" relationship (provider model, for instance.)
Where you have shared functionality, programming to the interface is more important than inheritance.
Essentially, inheritance is more about relating objects together.
Most of the time we are concerned with what an object can DO, as opposed to what it is.
class Product
class Article
class NewsItem
Are the NewsItem and Article both Content items? Perhaps, and you may find it useful to be able to have a list of content which contains both Article items and NewsItem items.
However, it's probably more likely you'll have them implement similar interfaces. For example, IRssFeedable could be an interface that they both implement. In fact, Product could also implement this interface.
Then they can all be thrown to an RSS Feed easily to provide lists of things on your web page. This is a great example when the interface is important whereas the inheritance model is perhaps less useful.
Inheritance is all about identifying the nature of Objects
Interfaces are all about identifying what Objects can DO.
My class hierarchies tend to be fairly flat as well, with interfaces and composition providing the necessary coupling. Inheritance seems to pop up mostly when I'm storing collections of things, where the different kinds of things will have data/properties in common. Inheritance often feels more natural to me when there is common data, whereas interfaces are a very natural way to express common behavior.
The answer to each of your 3 questions is "it depends". Ultimately it will all depend on your domain and what your program does with it. A lot of times, I find the design patterns I choose to use actually help with finding points where inheritance works well.
For example, consider a 'transformer' used to massage data into a desired form. If you get 3 data sources as CSV files, and want to put them into three different object models (and maybe persist them into a database), you could create a 'csv transformer' base and then override some methods when you inherit from it in order to handle the different specific objects.
'Casting' the development process into the pattern language will help you find objects/methods that behave similarly and help in reducing redundant code (maybe through inheritance, maybe through the use of shared libraries - whichever suits the situation best).
Also, if you keep your layers separate (business, data, presentation, etc.), your class diagram will be simpler, and you could then 'visualize' those objects that aught to be inherited.
I wouldn't get too worried about how your class diagram looks, things are rarely like the classroom...
Rather ask yourself two questions:
Does your code work?
Is it extremely time consuming to maintain? Does a change sometimes require changing the 'same' code in many places?
If the answer to (2) is yes, you might want to look at how you have structured your code to see if there is a more sensible fashion, but always bearing in mind that at the end of the day, you need to be able to answer yes to question (1)... Pretty code that doesn't work is of no use to anybody, and hard to explain to the management.
IMHO, the primary reason to use inheritance is to allow code which was written to operate upon a base-class object to operate upon a derived-class object instead.