Mohsen Vakilian's Blog

March 8, 2008

A Good Use of final

Filed under: design — mohsenvakilian @ 10:02 pm

The Template Method Pattern could be a case in which you might really want to use final methods.

“… They [Template methods] are particularly important in class libraries, because they are the means for factoring out common behavior in library classes.” [GoF]

In the template method pattern, it’s important to know which operations to override and which not. And, the final keyword in Java is a mechanism to achieve this.

October 2, 2007

Expander—A New OO Construct

Filed under: design — mohsenvakilian @ 5:28 pm

Expanders introduced in a paper by Wart et al, are new constructs for Java to support object adaptation.

The idea of expanders was not so new to me for I’ve seen similar and simpler mechanisms in Ruby.
I think the exploratory study of Eclipse was quite promising. Although this study shows some shortcomings of eJava (Java + Expanders), it proves the usefulness of expanders in a large software which has extensibility as one of its most important goals of its architecture. Eclipse architecture has done a great job of incorporating all that extensibility. Eclipse architects would have had an easier job if they had eJava in hands!

Expanders are complex. As a proof, here are some rules about expanders:

  • “A method in an expander cannot override an ordinary method of the associated class.”, p. 3.
  • “We disallow overriding expanders from declaring members that are not declared in the top expander.”

However, ordinary developers don’t need to deal with expanders so much. Probably, those developers dealing with writing libraries and plug-in get the most benefit out of it.

The most important difference between expanders and regular methods of implementing the adapter design pattern is that in adapter design pattern the adapter introduces a completely new interface using an adaptee object. However, using expanders one just expands (i.e. adds methods, attributes, …) to adaptee. So, the adapter still supports the adaptee interface. And, this support of adaptee in the adapter might not be what the developer means when he says I’m using the adapter design pattern.

One might be interested to improve their work by adding the support of generics to eJava. Also, one might be willing to investigate if other constructs can be added for other design patterns.

My question is whether or not Dependency Injection frameworks such as Spring and Guice can do the job of expanders.

June 15, 2007

A Good Example of friend!

Filed under: design — mohsenvakilian @ 2:47 pm

What do you say if somebody comes to you and says: “What’s this ugly friend keyword in C++ for?” or “What is the real use of Java’s package access?”

Here is an elegant example: The State Design Pattern! You may take a look at the class diagram of its structure in my previous post.

If you want to distribute the state transition logic among State subclasses, you have to define a “changeState()” method in Context.
This method has to be private in C++ and Statehas to be declared as a friend of Context. Also, in Java, you can put the State and the Context classes in the same package to use the package access.

The Similarity Between State and Strategy Design Patterns

Filed under: design — mohsenvakilian @ 11:48 am

They are quite similar! Just take a look at the class diagrams of Strategy and State design patterns, below.

Class Diagrams of Strategy and State Design Patterns

So, why have GoF separated them as two distinct design patterns?

First, let’s explore the similarities a bit more. Both have a concept of delegation to an abstract class which is an interface to a hierarchy of different subclasses.

I think the main difference among these patterns is the different contexts in which they are used. Even though the class diagrams of these patterns resemble a lot, their intents are completely different. The State design pattern is used for objects having different states in their lifetime where the objects exhibits different behaviors in different states. On, the other hand, the Strategy design pattern is used for customizing an algorithm by passing an object as a part of it.

Another difference is the lack of the concept of transitions in the Strategy design pattern. In fact, Strategy is not as dynamic as State. So, the need to change the reference to its object isn’t strong.

In spite of the similarities between several design patterns, I believe that drawing such relationships and abstractions among these patterns is quite useless! In fact, nobody sees any strong similarity between Strategy and State design patterns normally.

Blog at