I have two designs which achieve the same result.-------Design AMainClass 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 Bmainclass 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?
Which design is better? [MainClass] -> [Class] OR [MainClass] -> [MiddleClass] -> [Class]
design
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.