Timeline for Builder pattern inside interface. Bad design decision?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 13, 2020 at 19:04 | comment | added | Ferdinand Beyer |
Not sure if the circular dependency is a problem at all. A use case for this design might be that you create a nicer API -- think DSL. For example, the Map.of() family of static methods of the java.util.Map interface will create concrete maps using other top-level classes that in turn depend on the Map interface. Not a problem at all. Using Map.of() to create an empty map is certainly a nicer API than having to resort to something like MapFactory.create().
|
|
| Jul 15, 2014 at 10:26 | vote | accept | mhi | ||
| Jul 15, 2014 at 7:21 | comment | added | mhi |
You are right, the circular dependency is problematic. One could resolve this by mimicking the Builder's build() method from the example you provided and setting the PersonImpl's fields to protected. But then one would need to keep the package very small to keep the class effectively immutable.
|
|
| Jul 14, 2014 at 18:39 | history | edited | sea-rob | CC BY-SA 3.0 |
added 4 characters in body
|
| Jul 14, 2014 at 18:33 | history | answered | sea-rob | CC BY-SA 3.0 |