Open for extension, closed for modification. The open-closed principle is on the of the great object oriented design principles of our time. Its a design principle that is very fragile where the smallest of changes can easily undo the closed-ness of a system. So, l’ll to summarise the principle for the purposes of our discussion, and to allow me to make some assertions on the validity of the principle for Enterprise Business Systems.

The open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” [Meyer, Bertrand (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0136290493]. In principle, each software entity can allow it’s behaviour to be changed without the alteration to it’s source code.

So, l’ll start by giving an example of a successful outcome for the Open-Closed principle. My last project required the extension of Spring to enable some extra behavior during bean factory construction. So, we hunted and found the Spring class that implemented the XML file parsing and decided to extend the functionality. It was really simple, NewSpringClass extends SpringClass, then add the new behavior. Done! I did not need to download, modify then build the Spring code to add the new behavior. The Spring classes were implemented in a way that allowed for simple extension, otherwise we could have found ourselves doing things that we should be banished for doing.

Now, lets look at another modification scenario; changing business requirements. As new business requirements become known, we need to add new or modify old behavior of the system. How often is this done by extending the functionality of a system classes instead of modifying them? Well, thinking back, extension is rarely done, it’s mostly modification.

For example, when the business want the behavior of the system to debit accounts in a scenario instead of crediting the account, this will most definitely result in a modification. Does this mean that l’ve not implemented by Enterprise System correctly? Fortunately enough, this is not the case. I’ve used most of the good design practices like keeping my concerns separated, ensuring that my layers are well defined, designed my service interfaces at the correct granularity, avoided anti-patterns, etcetera. So, why is it that my changes to the Enterprise System is mostly modification?

The answer is the rate of change of the system during a standard development process. Behavior and functionality of a framework like Spring can be defined priori, where the changes of system requirements is significantly smaller than the change expected from Enterprise Systems. So, the Open-Closed principle breaks down when the requirements of a system are unpredictable. That’s the definitive point.

So, given l have demonstrated that the rate-of-change of Enterprise Business Systems has the propensity to force the Open-Closed principle out the door, what other options do we have in this architectural domain?  I believe that there are many; although the answers may not be in other patterns or principles.  All solutions in this domain need to be carefully considered where options of each solution carefully weighed-up, prioritised and recorded.  Applying a pragmatic view will always present a viable, well thought out solution.

Asking anyone about the importance of getting your applications business tier design and implementation right will draw no objections. A well designed and implemented business tier increases the flexibility and maintainability of your application and shields it from complex and difficult refactoring imposed by changing requirements.

Over the years, l’ve seen well designed and implemented business tiers by the use common design patterns such as Command, Data Access Objects, Service Facade etc. If well implemented, these design patterns can increase the maintainability of the application and increase the business agility to evolving business requirements. From my experience, the same cannot be said about the View.

Ive seen a number of projects fail dismally in the view implementation where changes are typically complex and difficult to implement. Frameworks like Spring MVC and Struts are great to help organise application layers and apply constraints to help avoid abstraction leakage (like business logic bleed into the view) and provide a clean MVC framework, but is still not sufficient for Web Tier agility. The technology ecosystem for the Web Tier is vast with new and constantly evolving frameworks which increase the richness of the web experience. AJAX, JSP, Velocity, Tapestry, Java Server Faces are all excellent tools in implementing your view and all present a number of rich API’s to help in the rendering and behavior of the view.

That said, what I’ve found missing in Web Tier implementations is a consistent lack of organisation. So what do l mean by “organisation”? Using the business tier as an example, typically most database access detail are hidden behind a Data Access Object API. This way, as long as business services are coupled to the DAO API’s, then changes to the data abstraction code is localised in one area; the implementation of the Data Access Objects. This is the classic Separation Of Concerns. In my experience, concerns of the View have not always been adequately separated.

Most projects that l’ve worked on have not able to even articulate the View concerns. So, what are the concerns of the View? Well, simple. Markup, Style and Behavior. Separating these layers in the view is crucial to increase flexibility and maintainability of your view. Separating the Markup, Style and Behaviour of an application requires diligence and strict adherence to a few rules:

(1) - Ensure that your markup is limited to structural definitions and conforms to XHTML (Strict, Transactional or Frameset). The rule is to exclude any style or behaviour code. Here’s is an example of bad markup:

<html>
    <body style="background: #fff; alignment: left;" onclick="doSomeWork()">
        <ul style="list-style-type: none">
	    <li>A List Item</li>
        </ul>
    </body>
</html>

The above example mixes all of the View concerns. Firstly, there is style definitions in the <body> tag where the background is set to some arbitrary value and the alignment is set to left. Some style information has now leaked into the markup and will force the developer to search for and change each instance of the <body> when the application is being “re-skinned”. This same problem is repeated in the unsorted list definition, where the style of the list has been hard coded into to markup.

Secondly, the <body> tag has been defined to handle the onclick event from the document body. Similar to the first problem, refactoring the behaviour of the <body> will force the developer modify every <body> in the application when there is a change required in this area.

(2) - Ensure that Style is separated from the markup. This enables your applications view to be changed with minimal effort. When marking up the documents block elements, ensure that you use id and class attributes to decouple the markup from the style. This way, with the use of CSS selectors, style can be added to the markup and can be changed across the whole site using a single definition.

(3) - Ensure that Behaviour is separated from the markup. Once implemented, there should be only one JavaScript function call in your markup, which is typically <body onload="onload()"/>. Given that rich web view implementations require JavaScript, avoiding it is not practical, therefore attachment of events should be defined in a JavaScript file and called from the onload() call path.

/**
 * The onload() method that separates the markup from the behaviour
 */
function onload() {
    attachEvents();
}

/**
 * Attatchement of all events in the document
 */
function attachEvents() {
    document.getElementById("foo").attachEvent("onclick", bar);
    // Attatch all the events for document
}

/**
 * Event handlers.
 */
function bar() {
    doSomethingForOnClickEvent();
}

There you have it. Clean separation of all your View concerns. If you ensure that Markup, Style and Behaviour have been adequately separated, then you will have a more agile View, where skinning the application can be performed in far less time.

After my blog on Aspects of Spring on a monolithic codebase, lve been searching about the topic and, to my surprise, have not been able to find any posting relating to this or similar issues. Nor have l been able to locate any documentation or papers regarding this aspect of spring usage. Well… l think its time to lay claim to a pattern.

After some thought, lve decided to call it Single Bean Factory per Classloader. And the description of the pattern is:

When constructing a Spring Bean Factory, ensure that you have a single instance of the bean factory per-classloader and you load the spring application context files from a standard location in the classpath.

What does this equate to? Well, lets me describe the pattern by giving an example from the trenches: A J2EE application (EAR) that contains an EJB and Web Module.

In the complex innards of an J2EE Application Server, there are a few truths that we can rely on. One of these truths is that an EAR will have a classloader all to itself. Therefore, all JAR’s packaged at the EAR level will be on the EAR’s classpath *automagically*. The EJB module will always share the EAR’s classloader, in fact, they are deployed as a single JAR in the root of the EAR. Web modules, on the other hand, do have a separate classloader, but the WAR’s classloader will be the EAR’s classloaders child. Therefore, the EAR and the WAR have a parent child relationship w.r.t classloaders.

Why do l need to know this, l hear you ask? Well, its all about scope. As the Single Bean Factory per Classloader pattern suggests, a core principle is the single instance of the Bean Factory per classloader. Therefore the object that constructs the Spring Bean Factory must be on the EAR’s classloader and not on the Web Modules class loader. How do you guarantee this? Package the Bean Factory Singleton wrapper into the EAR level. You can then instantiate the Singleton Bean Factory wrapper from the EJB module or Web Module and you’ll be guaranteed to have a single instance.

Now that we have a clear understanding of “the classloader aspect”, lets talk about the second principle; “load application contexts from a standard location”. This way, you can abstract the dependency aspects of your spring defined components to be managed by the a dependency tool, like Ivy and link them from your components on the classloader. What the hell does this mean? Well, you have not read blog entry Aspects of Spring on a monolithic codebase! For those who have not read it, l’ll summarise. Its real simple; ensure that you have one or many (keep it consistent though) number of “main” spring application context xml files that you stored in a standard location in the JAR, i.e. META-INF/components. That way, the code to find the application context files is generic:

getClass().getClassLoader().getResources("META-INF/components/components.xml");

There you have it. This pattern has the capability to really increase the manageability of your spring based applications. Enjoy.