use Perl

• Inheritance is not the answer. (Score:2)

  by brian_d_foy (44)

  What's really broken is that people think you need to inherit everything. In your example, it looks like you have a cart that should have things, not inherit things. I know this lame example shows up in a lot of Java books, but it's the wrong use for inheritance. They usually pull this stuff out to explain decorators, too, which is a pattern that is almost never needed for the example given.
  
  There's no reason that any of those things should have an Is-A relationship. You need a cart that contains other disti
  • Re: (Score:1)

    by jk2addict (4946)

    There's no reason that any of those things should have an Is-A relationship. You need a cart that contains other distinct objects,

    That's not exactly true in .NET. The Cart whould returns a strongly type collection of CartItems, not a mishmash of Object that then have to be inspect just to see what they are. And I don't understand that statement about no reason for IS-A. A CartItem IS a part...period. 100% percent of the time. You can't buy anything that's not a part...but I digress... Well sure, you coul
    • Re: (Score:2)

      by gav (2710)

      That's not exactly true in .NET. The Cart whould returns a strongly type collection of CartItems, not a mishmash of Object that then have to be inspect just to see what they are.

      It would make more sense to return a collection of objects that share similar interfaces, where these interfaces define the actions that you want to do with these objects.

      Your cart could return a collection of objects that can be IOrderable, IShippable, etc, where these are characteristics of these objects.
      • Re:Inheritance is not the answer. (Score:1)

        by jk2addict (4946) on 2007.05.26 11:32 (#55292) Homepage Journal

        Right. I don't disagree with that statement as a solution.
        
        Again, by using interfaces, each different type of object has to reimplement the same code the implement the interface. That's a waste of effort when inherts takes care of that problem. To avoid duplicating code for all different types of objects implementing IPart, they'de all have to use another class..which even more effort for no good reason.
        
        We're not talking about unrelated objects in a collection ACTING like a part (via a common Interface), we're talking about all objects that ISA (are) a part implementing the same code.
        
        There is a difference there. And for the sake of this topic, remember an Interface in .NET is not the (only) API of the class nor the code....it's just a interface contract describing behavour, not the code implementing it.
        
        The use of Interfaces means you have to duplicate code to implement that interface somehow, somewhere making the solution more complicated that just using SI/MI.

        Reply to This

        Parent