I’m working on a java project for the university. The project is a card game in which you travel around a 2D map and fight against some enemies. My part consists of creating the deck and the cards.
I made the card interface, an abstract card and an implementation that extends the abstract card and implements the interface.
Now I also want an internal static builder in the abstract class and a related builder implementation in all classes that extend the abstract class (because if the new card has a new field I also want to add it in the builder). I have extended the builder in the implementation, but I don’t know if it is correct to extend a static class.
The idea came to me from:
Effective Java, 3rd edition, Joshua Bloch, Item 2: Consider a builder when faced with many constructor parametersconstructor parameters
The question is: Is it correct to extends a static inner class?
Because what I would mainly like is to “force” all classes that extend the abstract class to have a builder, since the constructor has many parameters.
1
You are facing an Open/close dilemma:
- The abstract card is meant to be open for extension but closed for modification.
- At the same time you want to force all extension to implement the builder pattern, which only takes the currently known construction parameters.
- As a result, the extension is less open than it could: what if a concrete implementation of your card, for a variant of your game, would need more parameters for its construction?
Bloch’s builder pattern is primarily meant for dealing with many constructor parameters. If you want to generalize the construction process, independently of the concrete classes to instantiate, you may better look at GoF’s more general builder pattern, which aims to:
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
This pleads for decoupling the builder from the abstract class.
No, roughtly speaking, there is nothing wrong in defining a subclass of an inner class, static or not, at least a priori.
An inner class has a strong coupling / dependecy with its holding class. Thus, if a class called ANY “uses” an inner class called INNER which is defined as a inner class inside the class called HOLDER, ANY need to know both INNER and HOLDER definitions. In Java terms, it means that HOLDER and INNER must be in the same classpath of class ANY if ANY uses INNER.
Here “uses” means a parameter type, a local variable, a method call, an attribute or, as in your case, an inheritance relationship.
Thus, a subclass of the INNER class needs to know the HOLDER class as well. And any other class which uses this subclass of INNER eventually will need to know the definition of HOLDER in the same classpath.
The point if all those coupling is valid or has nothing about the fact that the class is a specialization of an inner class or not. The MDL principle suggests that the coupling is valid if it is necessary. If it is not required to a class know another class, the dependency may be avoided, allowing a more reusable and maintanable code. Hence, you would ask yourself: is there a context where the subclass of INNER can be used without the presence of the HOLDER class definition? If yes, it is time to a refactor, moving INNER to outside HOLDER. By the concrete use case of the game cards you illustrate, I don’t think it would be the case, so define a subclass of your inner builder looks fine.
Finally, being static inner class makes using INNER and its subclass easier (because you needn’t a proper instance of HOLDER at hand to use them). But it doesn’t change the dependency hierarchy described previously.