Despite the enthusiasm the authors had about their theory and product, the conclusion and reasoning behind it are rather naive. First of all, they used a very generalized and high-level definition of design pattern to start their argument. They explained that “A design pattern is an architectural solution to a frequently encountered software design situation”. Take a first look at this definition, it seems that design pattern is kind of similar to component, which is defined as “A system element offering a predefined service and able to communicate with other components.” in Wikipedia, but if you take a closer look, you will realize the key difference between design pattern and component is basically although both of them are aimed at reusability, design pattern is created to address design and communication issues rather than being a off-the-self solution that address issues in a problem domain as what component is designed to do. Now you will realize that the first argument they put up that design pattern only describes a solution but not the solution itself is not the weakness of design pattern, and in contrary the nature of design pattern. Based on this weakly established basis the authors start using examples to try to convince reader how much better that components could be, which inevitably led them to make another mistake in which they picked some classic design patterns such as Visitor and Bridge to serve as their examples. If before they are just comparing orange with apple (at least they have similar size and both of them are fruits) now they are comparing building with bricks, since now they are not comparing componentization with some conceptualized definition of design pattern but some concrete design patterns in object oriented realm. If you are familiar with the evolution of software design, you will realize that there are different level of encapsulation/abstraction existing in this domain:
- Level 0 – No encapsulation
- Level 1 – Macro or function level encapsulation
- Level 2 – Class level encapsulation (usually referred to Object Oriented design philosophy)
- Level 3 – Component level encapsulation
- Level 4 – Service level encapsulation
As you can see that design patterns and componentary live on different planes of encapsulation/abstraction, comparing them does not make any sense, it is like comparing service with component. The same argument can be made the component is just the description of a part of solution (from service point-of-view) not the solution itself therefore it is not good enough, hence why bother creating component we should just focus on making ready to plug-and-play services, a process we call servicise.
To summarize here, I am not trying to say that design pattern is perfect and we should use them at all cost. In contrast I agree with some of the harshest criticism (you can have a peek of them here) out there against design pattern, but compoentization is definitely not the solution to these problems.