My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox

EclipseCon

March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture

Catalyst

July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response (http://t.co/KrN8XNWg) to the @mreinhold #jigsaw announcement (http://t.co/9YvcDdqC). 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. http://t.co/9YvcDdqC. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

On SOLID Principles & Modularity

Filed Under Architecture & Design, Development, Java, OSGi |  

I stumbled across Uncle Bob’s SOLID principles of OOD quite a few years ago. They serve as the foundation of knowledge for designing object-oriented software. In fact, if you analyze the GOF patterns, you’ll find that virtually all of them adhere to the class design principles. I felt strongly enough about these principles that I included them in Chapter 1 of JOUP.

When used judiciously, they serve as excellent guidance in designing object-oriented software. But it’s not the SOLID class design principles I want to talk about here, at least not exclusively. Instead, it’s their less famous brethren that are often lost in the discussion of the SOLID class design principles…the principles of package design that I want to discuss.

Not Package. JAR File!

The ill fate of the package design principles is not due to their lack of value, but due to misinterpretation. As a result, the package design principles are not used nearly as widely as the SOLID class design principles. The obvious reason for this is that more teams spend time designing class relationships than anything else. Anecdotal evidence has shown this to be true. But this is not the only reason. Another surrounds their perceived value, and this is where misinterpretation of the package design principles plays a crucial role. Instead of the package design principles, they should be referred to as module design principles.

I’m unsure why the term package was initially chosen, but I postulate that at the time the principles were documented, C++ was the target language. Unfortunately, when translating these principles to Java, the mapping between the package principles and Java packages was carried over literally, and the foundation for misinterpretation was born. For example, JDepend is a tool that reports the measurements related to many of the package principles, but does so for Java packages. The literal interpretation of the package design principles when translated to Java packages diminishes their value.

Don’t get me wrong. There is value in taking care to design Java packages, but there is greater value when applying the principles to design JAR files. In fact, the principles map more clearly to JAR files than Java packages, and the Reuse Release Equivalency principle supports this point by stating:

The granule of reuse is the granule of release.

The granule of release in Java is the JAR file, not the package. The greatest value of the package design principles is not when applied to Java packages, but when applied to Java JAR files. We recognize this today, but it hasn’t always been that way, and initial interpretations along with a misleading naming convention still lead people astray. It did me, initially. But my discoveries in applying these principles are also what led me to develop JarAnalyzer a few years ago.  I finally recognized the value in applying these principles to  JAR files. And combining the package (can I say module now?) design principles in conjunction with the SOLID class design principles sheds an entirely new and interesting light on how we go about designing large enterprise software systems.

SOLID Design

In his recent blog entry, Uncle Bob provides insight to how you might get started with the SOLID principles. It’s tough work. Similarly, I recall working hard to learn the GOF patterns in the mid-90’s. They twisted my brain like a pretzel, but over time, through study and application, I was able to grasp and master many of the concepts. A key element I had to learn is that the patterns don’t represent a universal truth - they shouldn’t always be used. You have to recognize where the extra flexibility is worth the increase in complexity. It’s the same with these principles. Uncle Bob makes this point clear in his discussion of the SOLID principles, as well:

These principles are heuristics. They are common-sense solutions to common problems. They are common-sense disciplines that can help you stay out of trouble. But like any heuristic, they are empirical in nature. They have been observed to work in many cases; but there is no proof that they always work, nor any proof that they should always be followed.

That being the case, what are the most important areas of the system that need a SOLID design?

Joints, Modules, & SOLID

Every system has joints, which is the point where two modules connect. It is these joints within the system that require the greatest flexibility and resiliency. The reason for this is driven by change. Change that is encapsulated within a single module poses less threat than change that ripples across many modules. This is trivial, and it’s why changing the private methods of a class are easier than changing the public methods. Likewise, change confined to a single module is easier than change that spans modules. That’s logical. So if we’re able to create well-designed modules, it makes our life a little bit easier.  And using the module design principles allows us to bring greater modularity to our applications if we apply the principles when designing JAR files.

It is these joints, or module boundaries, within a system that represent the ideal opportunity to leverage the SOLID principles. Using the SOLID principles to minimize coupling between JAR files offers the biggest bang for the buck. Realistically, we cannot make an entire system open for extension but closed to modification (the Open Closed Principle). But we can use OCP at the module boundaries (aka. the joints) to create JAR files with enough design flexibility to confine change to a single module. Using the SOLID principles when designing the relationships between modules provides a low barrier point of entry for using these principles to create better designs. For instance, it’s much easier to refactor the classes if we know the refactoring is confined to a single JAR file. With a rich suite of unit tests, we can prove it has no impact to the outside world. But if we have to refactor the classes and the refactoring spans the joints of the system, well…that’s an architectural refactoring. It gets difficult and messy.

Today, technologies such as OSGi and JSR 294 aim to leverage the JAR file in bringing greater modularity to the Java platform by treating the JAR file as a first class component. It’s why these technologies are so important…they make it just a little bit easier to design really big software systems. And if we apply the SOLID principles in conjunction with the module principles, we have guidance on how to best design large software systems. As interest in designing more modular software continues to increase, and especially as OSGi continues to gain momentum, the module design principles will grow in importance.

Comments

11 Responses to “On SOLID Principles & Modularity”

  1. Rebecca on February 25th, 2009 6:13 pm

    You are pointing out, aptly that a configuration specification (e.g. the JAR file) is a thing in and of itself that needs to be managed…it is important to separate a specification of a workable config from its implementation. I got trained up to that way of thinking back when I used ENVY in Smalltalk (I was the release wonk for one of the oscilloscopes at Tektronix…)

  2. Agile Architecture : Software & Technology @kirkk.com on May 6th, 2009 6:49 pm

    [...] software that can easily adapt to change. I provide an example of how to do this by focusing on the joints within a system. In practice, developing agile architecture is much more difficult. There are two simple truths we [...]

  3. The Two Faces of Modularity & OSGi : Software & Technology @kirkk.com on June 23rd, 2009 4:03 pm

    [...] provide some insight to how we should go about doing this in my post On SOLID Principles & Modularity. Of course, these are simply top level concepts. There are numerous principles and patterns that [...]

  4. Modularity Patterns : Software & Technology @kirkk.com on August 5th, 2009 3:26 pm

    [...] Modularity patterns provide guidance and wisdom in helping design modular software. They explain ways that we can minimize dependencies while maximizing reuse potential. They help balance module weight and granularity to make a system easier to understand, maintain, and extend. For those who have attempted to design modular software, it’s common for modularity to drive the logical design decisions, which I briefly explained when discussing the SOLID design principles. [...]

  5. Agile Architecture at Upcoming Conferences : Software & Technology @kirkk.com on August 11th, 2009 2:44 pm

    [...] On SOLID Principles and Modularity - Discusses where you need flexibility in architecture. [...]

  6. Modularity Pattern - Manage Relationships : Software & Technology @kirkk.com on September 2nd, 2009 3:31 pm

    [...] between those modules. It’s these relationships between modules that I refer to as the joints of the system, and it’s these areas of the system that demand the most nurturing to ensure a flexible [...]

  7. Agile Architecture Presentation : Software & Technology @kirkk.com on September 11th, 2009 6:01 pm

    [...] On SOLID Principles and Modularity - Discusses where you need flexibility in architecture. [...]

  8. The Use/Reuse Paradox : Software & Technology @kirkk.com on October 7th, 2009 5:04 pm

    [...] principles, patterns and practices (like SOLID and modularity patterns) that increase architectural agility help resolve the tension between use [...]

  9. Chapter 7 – Reference Implementation : Modular Architecture on December 21st, 2009 7:36 pm

    [...] the modules become more apparent as development progresses. With a SOLID OO design (reference to SOLID principles here), it’ll make it much easier to move things around and create new modules. So to start, while the [...]

  10. Manage Relationships : Modular Architecture on December 22nd, 2009 2:07 am

    [...] relationships between those modules. It’s these relationships between modules that I refer to as the joints of the system, and it’s these areas of the system that demand the most nurturing to ensure a flexible system [...]

  11. Chapter 6 – Realizing Reuse : Modular Architecture on December 29th, 2009 9:13 pm

    [...] Modularity patterns provide guidance and wisdom in helping design modular software. They explain ways that we can minimize dependencies while maximizing reuse potential. They help balance module weight and granularity to make a system easier to understand, maintain, and extend. For those who have attempted to design modular software, it’s common for modularity to drive the logical design decisions, which I briefly explained when discussing the SOLID design principles. [...]

Leave a Reply