Should a parent class ever reference child classes?

Question

Good morning,

I inherited some legacy code at work and it is using a rather unusual design pattern. The only reference I could find on the forums to a similar patter

Answer 1

It is a good practise and called Factory Method.

The benefit is that you return some concrete implementation but hide it via common interface or base class. Thus client isn't bothered by implementation details, but works with a most basic class.

Answer 2

Whether this is a good or bad practice it depends on situation. Eg when the 'parent' knows how to create all the children, it may be a good practice. When the parent doesn't know it, this solution will only cause trouble.

Another problem is testability: if parent has lots of children, it may be hard to create parent in isolation from the children, but again it depends.

Answer 3

It's a very standard pattern in Java, and a common way to implement a Strategy pattern. You see it in the standard API all the time (Calendar vs. GregorianCalendar, NumberFormat vs. DecimalFormat and more).

That being said, with Dependency Injection being all the rage, such a pattern might indeed be replaced by a dedicated Factory class with a dedicate Factory interface, but in the absence of a larger design reason, I think the example you give is a perfectly reasonable design choice.

Answer 4

Maybe they have it setup that way to use Log4J in one environment, and Logback in another? I know sometimes developers prefer a tool when doing local development, but when it comes time to deploy have to use whatever the company endorses/approves.