Introduction to Java Application Architecture: Modularity Patterns with Examples Using OSGi
This chapter is from the book
This chapter is from the book
This chapter is from the book
In 1995, design patterns were all the rage. Today, I find the exact opposite. Patterns have become commonplace, and most developers use patterns on a daily basis without giving it much thought. New patterns rarely emerge today that have the same impact of the Gang of Four (GOF) patterns.1 In fact, the industry has largely moved past the patterns movement. Patterns are no longer fashionable. They are simply part of a developer’s arsenal of tools that help them design software systems.
But, the role design patterns have played over the past decade should not be diminished. They were a catalyst that propelled object-oriented development into the mainstream. They helped legions of developers understand the real value of inheritance and how to use it effectively. Patterns provided insight into how to construct flexible and resilient software systems. With nuggets of wisdom, such as “Favor object composition over class inheritance” and “Program to an interface, not an implementation” (Gamma 1995), patterns helped a generation of software developers adopt a new programming paradigm.
Patterns are still widely used today, but for many developers, they are instinctive. No longer do developers debate the merits of using the Strategy pattern. Nor must they constantly reference the GOF book to identify which pattern might best fit their current need. Instead, good developers now instinctively design object-oriented software systems.
Many patterns are also timeless. That is, they are not tied to a specific platform, programming language, nor era of programming. With some slight modification and attention to detail, a pattern is molded to a form appropriate given the context. Many things dictate context, including platform, language, and the intricacies of the problem you’re trying to solve. As we learn more about patterns, we offer samples that show how to use patterns in a specific language. We call these idioms.
I’d like to think the modularity patterns in this book are also timeless. They are not tied to a specific platform or language. Whether you’re using Java or .NET, OSGi,2 or Jigsaw3 or you want to build more modular software, the patterns in this book help you do that. I’d also like to think that over time, we’ll see idioms emerge that illustrate how to apply these patterns on platforms that support modularity and that tools will emerge that help us refactor our software systems using these patterns. I’m hopeful that when these tools emerge, they will continue to evolve and aid the development of modular software. But most important, I hope that with your help, these patterns will evolve and morph into a pattern language that will help us design better software—software that realizes the advantages of modularity. Time will tell.
Object-Oriented Design
Over the past several years, a number of object-oriented design principles have emerged. Many of these design principles are embodied within design patterns. The SOLID design principles espoused by Uncle Bob are prime examples. Further analysis of the GOF patterns reveals that many of them adhere to these principles.
For all the knowledge shared, and advancements made, that help guide object-oriented development, creating very large software systems is still inherently difficult. These large systems are still difficult to maintain, extend, and manage. The current principles and patterns of object-oriented development fail in helping manage the complexity of large software systems because they address a different problem. They help address problems related to logical design but do not help address the challenges of physical design.