Suggest me a design RRS feed

  • Question

  • Hi,
     I have a design problem

    1.  Class Car which has method GetEngineType
    2 . Abstract class Company which has 2 methods Manufacture And Ship. Manufacture returns Car object
    3.  Class CarCompany which inherits Company and implements the two methods.

    Now i want to add a class called ToyCompany which Manufactures and Ships Toy. So what i did is i inherited from Manufacturer but the problem is the Manufacture returns Car type. Should i go ahead and create another base class called Product  from which both Car and Toy gets inherited? If i did it i will have different methods for Car and different methods for Toy how will i interact through interface Product?

    Please suggest me some ideas.
    Thursday, June 18, 2009 11:17 AM

All replies

  • I don't think having a CarCompany and a ToyCompany is a good idea.  You may end up with having a class for every company that manufactures a different product (ClothingCompany, PaperClipCompany etc.).  This is called inheritance explosion.

    initially, it seemed to me the general thing you want to model is organisations and their products.  Cars and toys have many things in common that could be generalised as  a product (cost price, materials, retail price etc.). 

    So my initial response was that you could have Organisations that manufacture Products.  Cars and Toys would be a specialisation of Products (inherit from).

    However, it seems to me that as you are including specific properties like EngineYype, you are trying to model something other than the generic products that organisations produce.  So maybe it isn't a valid design in your problem domain.

    These kinds of patterns are called analysis patterns and a good place to start is 'Analysis Patterns: Reusable Object Models' by Martin Fowler.

    Hope this helps.
    Pl mark as answer or helpful if you found this useful
    Friday, June 19, 2009 7:39 AM
  • This sounds a little like a design patterns example.

    Would you have a CompanyBase abstract class that has Manufacture and Ship, and a ProductBase abstract base class?

    You could then implement that basic wiring between the Company and Product, and derive your toy or car from product, with whatever methods are relevant to that product, and that company is then able to manufacture and ship both toys and cars.

    You could also derive a generic set of classes from CompanyBase and ProductBase so that you could construct a Company from CompanyBase<ProductBase>.  That said, personally I prefer interfaces, so Company : CompanyBase<typeof(CarProduct)> and CarProduct implements IProduct.

    Kind of difficult to go any further there with what I think you're trying to achieve without have a real scenario of how these entites would be required to work together.

    If the Toy company differs in it's functionality to the car company, i.e. it differs in more than just instance data, such as things that you would expect the company to do, then you probably would want to derive a specific class for each, and use the Base class, or an Interface to drive the polymorphic behaviour shared between all company objects.

    Hope this gives you some ideas - it's highly speculative, and probably not all that useful....


    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Thursday, June 25, 2009 5:57 AM
  • I agree with G Moore here.  You definitely need to refactor.  I would add that it's not uncommon for more derived classes to have different interfaces than their siblings that inherit from the same base class.  They just all have to have some common interfaces and those should be declared, if not implemented, in the base class.  Look up virtual base class .  You didn't indicate what programming language you are using so I won't give any concrete examples, but a virtual base class is one that has no implementation and only supplies interfaces declarations.  An inheriting class can either add more virtual interface declarations, provide some or all of the implementations or some combination of those.

    You just have to be careful about how you classify things.  You do have to beware of the aformentioned inheritance explosion problem.   It tends to make your code fat and brittle.  Think about abstractions; it's one thing to model a physical world for analysis purposes, but your implementation may need to come closer to modeling the model.  It all depends on the complexity level of the former and the likelyhood that the later will have to be changed over time to encompass new real world objects.

    Joseph w Donahue
    Sunday, June 28, 2009 5:36 AM
  • Thank you for all your time. I use c# as a language. 

    Yes i have CompanyBase abstract class that has Manufacture and Ship, and i thought of having ProductBase abstract base class so that i can genrealise the Manufacture and Ship methods to maufacture and ship any products.
    Monday, June 29, 2009 7:32 AM