In my ~ 20 years as Software Developer and Architect, it has always been unquestionable for me to aim for high quality in my software projects. I have especially appreciated to learn about Clean Code in the last 6 or 7 years. But recently I had a discussion with another external consultant about software development processes and practices, which showed me a completely different view. A view that might correspond indeed to the reality, but it’s definitely a view that occurs undesirable and ugly to me….
In this part I will show you a modernized, CDI-based version of the good old “Chain Of Responsibility” (CoR) pattern. As you will see, it is a perfect weapon if you want to design a system and write code that follows Uncle Bob’s “SOLID Principles”, especially the Open/Closed Principle, which is often one of the hardest to achieve.
The new design is based on an Interceptor that controls and performs the calls to the Chain Handlers, which have to be annotated with appropriate CDI-Qualifiers. The key difference to the usual Chain-Pattern is, that the chain handlers are not physically connected, i.e. a handler doesn’t know about any successor. Instead, the handlers are “virtually” connected by sharing a custom, Usecase-specific CDI-Qualifier, thus I would prefer to call this modernized version a “Virtual Chain Of Responsibility“.
Compared to the modernized factory-pattern, which I had shown in part 1 (see either the original post or the dzone-post), this CoR-design leads to an even more decoupled system, because you do not need to implement a factory anymore. Instead, it gets replaced by the generically implemented “ChainOfResponsibilityControllerInterceptor”. For an opensource implementation of this concept, see the section about the “magic4j-cdi-utils” library at the end of this article or visit magic4j.org.
Have you ever done the design of a layered application – usually representing a certain functional domain or microservice – consisting of the usual Web-, Façade-, Businesslogic- and Data-Access-Layers? Did that annoy you because of the continuously rising quantity of pure delegation methods in the Façade- and Businesslogic-Layer that produce nothing but “hot air” (and of course work overhead)? Then the CDI-based “Enhanced Eventdriven Service-Design” (“EESD”) is for you!
On first sight, the architectural style of REST via HTTP seems to constrain us to simple CRUD APIs: We operate on „resources“ which we often map rather exactly to our internal domain- / entity-types and we also mainly use the HTTP-Verbs GET (=retrieve), POST = (=Create + Update partly), PUT (=Update/Replace) and DELETE. But how can this fit if we need to implement some kind of business logic like validation, that is not directly related to one of the CRUD-operations? I want to show you a real life example and explain how I solved the problem.
In this first part of my upcoming series I’d like to show you a new way of implementing the “factory-method” pattern. To be more precise, it is what the famous “Gang-of-Four” call a “parameterized factory-method” in the Design Patterns-Book (see the “Implementation” section of the “Factory Method Pattern” on page 110/111). For simplicity I will use the term “factory-method” synonym to “parameterized factory-method”. The crucial point here will be, that the factory no longer needs any compile-time dependencies upon any concrete interface implementation. Furthermore I will explain how to write un-mocked unit-tests for a CDI-Bean (the factory) in order to be able to check that all the CDI annotations work as desired without having to start an application server.
Are you working on a project, that runs badly? Have you ever asked yourself if your project is doomed to failure? In this blog, I will list 10 signs, that may help you to find out.
Let me quickly tell you, who I am: I am working as an IT freelancer / consultant in the area of Java(TM) Enterprise Applications since 2000 and I must admit, that besides some successful projects, I also had to experience a few project failures. From that experience, I proclaim that it would have been possible for the decision makers to save a lot of money by stopping / restarting the projects earlier – they just should have been more aware of the signs themselves or they should not have been ignoring them for a too long time. Anyway, I would like to share my personal experiences in this area and of course I am interested in feedback about similar situations, that you have been going through…