I have two designs which achieve the same result.

-------Design A

enter image description here MainClass has a List and two methods. The methods create an autonomous object and is added to the list. The reason for the superclass, B and C are similar and I will be adding more subclasses. Furthermore, I can take advantage of polymorphism later on.

-------Design B

enter image description here mainclass has two methods. The method creates a aggregation link with MiddleClass and directly calls Mainclass methods - which returns an autonomous object of class b/c.

Unlikely A, B benefits from a higher degree of (loose)coupling from the MainClass, where the MiddleClass acts handles information from the inheritance hierarchy to the mainclass - And of course, the more subclasses I add, the mainclass will not have any additional links to the hierarchy, instead, it's all dealt with by middleclass.

However, I am not sure if I am just over-engineering the design or if it's a better design. What do you guys think is the better design and why?

  • I'm leaning towards the latter because the 'MiddleClass' is actually a factory, which means you can change the underlying functionality and not have to change any of the other classes. That said, I'm sure someone with more experience will have a more detailed answer for you.
    – Pharap
    Dec 24 '14 at 18:34
  • @Pharap thanks for the reply. I know fairly little about design patterns, hence I'm asking for advice but I also think in the long run, especially if a large number of subclasses are used, it will make it 'easier' to manage... I wonder if there is even a better design.
    – benscabbia
    Dec 24 '14 at 18:40
  • It's hard to say without knowing more about the exact situation (i.e. what the classes are used for), but if you go with option 2, I'd recommend creating an abstract version of the factory class and passing a concrete version of the factory into the MainClass's constructor. If your chosen language supports generics (I'm guessing you're using C++, C# or Java, in which case the answer is yes) you may want to just give the factory a single generic function so you can use the type parameter to decide which class to instantiate. But depending on your situation, that might be overkill.
    – Pharap
    Dec 24 '14 at 18:44
  • I'd agree with @Pharap, it looks like you're nearly at the factory pattern so it may be worth reading about it and seeing if it would apply well. The latter would also be matching more of the Single Responsibility principle of SOLID. Dec 24 '14 at 19:17

In both designs, MainClass has to know about ClassB and ClassC (and any future derived classes) to provide the methods to create and add new list elements. This makes that with the current interface for users of MainClass the first design is the simplest design and the best of the two.

However, it is possible to create a better design by decoupling MainClass and MiddleClass.
MainClass only needs to provide a method to add (already created) items to the list.
MiddleClass is actually a factory class, as already noted in the comments, and should be made available to the user to create the items that should be added to the list.

This way, MainClass doesn't need to be updated if new classes are added to the hierarchy, but only MiddleClass.

  • Hi Bart, thanks for the reply. You mention that I can decouple Mainclass and middleclass. Basically does this mean passing an object (created by middleclass) in the parameter for the method in MainClass?
    – benscabbia
    Dec 24 '14 at 19:33
  • @gudthing: Yes, that is what I mean. MainClass doesn't even need to know the exact type of the object, only that it descends from ClassA Dec 24 '14 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.