don to not use "Inheritance"

don to not use "Inheritance"

• flarmon

  pyeung wrote:

  Inheritance does have its place in OOP. When an class is "a-type-of" another class, it is easier to use inheritance. Example is as follows: You have an application for a Club House. The club has Gold, Silver, Ordinary and Child members. It is better to create a Member Class (usually an abstract class) and to inherit Gold, Silver, Ordinary and Child members from Member Class. Some people may argue that interface can do the same but I think inheritance is more suitable in this case.

  Agreed, but it's rare to see a situation this simple outside of an OOP textbook. In fact, I can't see any reason to bother with inheritance or interfaces in a case like this. The exception would be if there are properties that certain classes of members have that others don't (say, a "Dollars Contributed" field that Child members don't have). If you're creating new classes based on a simple distinction that could just as easily be made by an enumerated "MembershipStatus" property, you may be following the OO paradigm perfectly, but a practical look at it says that you're just making your code more complex.

  
  
  

• avinash kundal

  Inheritance does have its place in OOP. When an class is "a-type-of" another class, it is easier to use inheritance. Example is as follows:

  You have an application for a Club House. The club has Gold, Silver, Ordinary and Child members. It is better to create a Member Class (usually an abstract class) and to inherit Gold, Silver, Ordinary and Child members from Member Class. Some people may argue that interface can do the same but I think inheritance is more suitable in this case.

  
  
  

• HuskyNET

  The problem is in the way that OOP is taught.  OOP books and courses spend a lot of time on the topic of inheritance because it is difficult for some people to understand compared to aggregation/composition. Because of the disporportional amount of time spent learning inheritance, new OO programmers often think that OOP is all about inheritance and they forget about aggregation.

  Inheritance should only be used where polymorphism is helpful.  Polymorphism is a way to simplify code.

  For example, where logic contains a lot of branching based on a flag (especially when on an enum) I see this as a smell that polymorphism might help. In my current project, we have several types of sale invoice but they are all created by a single, monolithic creation object that contains a lot of if and switch statements (a direct port of old, procedural code).  This would be better served using a base sales invoice class and several polymorphic derived classes.  The resulting code will be more clear because of the reduction in switch statements.  I find this kind of issue a lot in business applications.

  Herbie

   

   

  
  

• cdolor

  Inheritance is a (pretty good) tool you keep in your bag for specific situations -- but not for every possible situation. For example, in ERP applications, my company doesn't define a customer object that, say, inherits from a lower-level "Person" object. We found that OO coupling between members of the data domain gave us little benefit. Worse, the business analysts that specify requirements who are experts in, say, cost accounting, had to buy off on the OO concepts, which added time to the analysis phase and didn't really give us any new reuse.

  The other issue driving some of our code away from inheritance is statelessness. Classes that are publically exposed do not have property members -- just operations. So, there is little need for inheritance as a data hiding mechanism.

  Having said all this, we still think polymorphism is really useful -- especially for frameworks to interact with application classes. You might not have supplier and customer objects inherit from a "legalBusiness" object, but they might inherit from a common base "DataDomainEntity" class with members that your framework uses (like call context information). But I also see more and more use of interfaces rather than virtual functions declared in a base class.

  Finally, our frameworks still use a lot of inheritance mechanisms and with good reason. Frameworks deal with more horizontal issues like serialization, security, transactions, logging, call context, etc. Those issues come with a lot of optionality, that we keep organized using a good object model. Anyway, there is no clear-cut answer (as usual), but I wanted to pass this along.

  
  
  

• wynfred

  Inheritance has its place. It is a powerful tool but it is relativly hard to get right - I usually have a a very shallow inheritance tree (Interface inheritance, on the other hand is easier)

  The main problem is that many people are not aware of Liskov's substitution prinicple (see http://www.ddj.com/blog/architectblog/archives/2006/08/liskov_substitu.html) and they create sub-classes that are awakward to use and maintain

  Arnon

  
  
  

• kastanienreis

  Agree with Yoni and want to echo GoF's own words (Gang of Four, the authors of "Design Patterns", 1995, 11 years ago)

  "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'"

  (The following taken from Wikipedia, on GoF's sentence, http://en.wikipedia.org/wiki/Design_Patterns)

  They warn that the implementation of a subclass can become so bound up with the implementation of its parent class that any change in the parent's implementation will force the subclass to change. They say that a way to avoid this is to inherit only from abstract classes--but then, they point out that there is minimal code reuse.

  They recommend using inheritance mainly when adding to the functionality of existing components, reusing most of the old code and adding relatively small amounts of new code.

  And the Golden rule, as a GoF's conclusion

  "Favor 'object composition' over 'class inheritance'."

  Of course that doesn't imply "Forbidden using Inheritance" but "Prefer Composition"

  
  
  

• Amadrias

  Ever worked with VB6 or tried to solve multiple inheritance

  VB6 did not provide support for inheritance and got slated for it. But those of us ex c++/java developers simply used aggregation and it worked well (as per GoF as others are pointing out)

  Plus aggregation was also a way of getting round multiple inheritance in C++ and java.

  Today doing c# I tend to use inheritance in building frameworks for technical solutions - controls etc. I tend not to use inheritance in the business layer. I guess the reason for this is that I am mainly using DataSet based business objects.

  
  
  

• Frederik Vanderhaegen

  I usually design with no inheritance at all and am happy with the results. Inheritance tends to make encapsulation harder to achieve and introduces the fragile-base-class problem.Using delegation and interfaces for polymorphism is a lot cleaner and more maintainable.
  
  
  

• daveW2007

  Yes, absolutely we could have aggregated the context info. We just chose the polymorphic approach to keep the context info declaration out of the descendent objects. It was a style decision, really.
  
  

• Timmy0614

  I forgot to mention that inheritance is a good way for a framework to get context information (like current user or other security or environment info) to a component. Rather than passing this stuff in directly in function declarations, the framework can instantiate the component and initialize the context data privately through the base class. I've also seen this done using thread-local storage, though.
  
  

• jay1234

  I've used inhertiance in one case where there where about 200 different forms in a sinlge application that all had the same basic look and shared basic functionality, but used different fields and logic. Altough you could do this in another way, at the time it worked like a charm. If you wanted to change something in the basic look or functionality of all the forms, just change the base class.

  I do agree with duck thing that these cases are rare.

  On the interface note, this can be handy when in need of some kind of plugin functionality, wich is used more often.

  
  

• rskorski

  I normally choose to work with inheritance when I know projects are or will get big (in source size).

  Inheritance is a good way to get rid of "libraries" that aren't realy libraries and still share code between similar functionalities.

  I do agree It's sometimes overrated. Classes are fine without inheritance. Inheritance is only there to share similar functionalities but still keep the code clean.

  
  

• Keith Hill

  erikj wrote:

  I forgot to mention that inheritance is a good way for a framework to get context information (like current user or other security or environment info) to a component. Rather than passing this stuff in directly in function declarations, the framework can instantiate the component and initialize the context data privately through the base class. I've also seen this done using thread-local storage, though.

  But couldn't you do this equally well through aggregation, with the aggregated object initializing context data privately

  Herbie

  
  
• don to not use "Inheritance"