Recently, I began reading Clean Code by Uncle Bob (again). In chapter 11 (“Systems”), he writes about a “Global Setup Strategy” of an application. As I understood it, it is the master plan for instantiation of objects and the references between them. Following such a strategy should separate the construction of a system from its usage.
To understand that concept, I thought about how it could be applied to a Spring-based project. Although the following figure positions classes in packages, the arrows are not meant to be references between objects, but instantiation paths. So if two classes are connected via an arrow, that means that the left class instantiates the right class.
Focusing only on the instantiation of objects, I think there are four phases of object-instantiation in my example Spring project:
- Build-up of the infrastructure - In Spring-based projects, Beans can be configured to be instantiated and referenced during startup of the application context by the Spring framework. This is called Dependency Injection. Very basic and necessary infrastructure, such as internationalization classes, basic Data-Acces-Objects (DAOs) and basic utility classes are often instantiated this way. The figure above shows an architecture that also handles services in the middleware as beans and instantiates them at application startup. The developer doesn’t need to concern himself with the instantiation process (but has to configure it).
- User Action - In my example, the interface is driven by controllers that controll the user interaction and handle any input. Some user actions cause controllers to instantiate other controllers to process the interaction. This could be to show another panel or website.
- Data Acquisition - Often, user actions cause loading of data. Here, services and DAOs are used to acquire the data and store it in a Data Transfer Object (DTO) to make it accessable for the controllers in the client. One or more DTOs are instanciated by services or DAOs in the process.
- Display data - To display the requested data to the user, new objects for the view have to be instantiated by controllers. They can be presenter-objects that serve as the basis for user interfaces or a JPanel if Java Swing is used.
Having given that a bit of thought, I recognized how important a clear rule set for the instantiation of objects is, especially in large systems. Using Bean-instantiation at startup, lazy Bean-instantiation, classic Java constructors and the factory pattern erratically increases the complexity of the system. There should be a clear rule set like the above that all developers of a team are aware of. That replaces complexity of the system with certainty during the development. Also, it enhances clarity in the architecture.