Frameworks: Increasing productivity with Spring?

I read this article on Spring and found it very usefull as a good starting point for myself. Having experienced the pain of writing testable and nice looking code in enterprise environments, I must honestly say that the framework looks promising.

http://www.onjava.com/pub/a/onjava/2005/05/11/spring.html

My first thoughts lead my mind back to the first time I started using EJBDoclet in conjunction with Maven (Wich I found reveloutionary at the time)

Since I knew the EJB 2.x Specification by heart I had no trouble finding my ways around cryptic error messages, generated descriptors with bugs in them, merge-files problems etc. I knew what all the generated stuff were supposed to look like.

So, The future will be very intersting; And a question came to mind

Do frameworks make you more productive before you know all the nitty-gritty details of all It's building blocks ?

Dependency injection, IOC patterns in general, Micro Containers and Hibernate are fairly new terms in my vocabulary. How much of this must I learn to get increased developer efficiency with Spring ? How much time will I spend debugging Hibernate code ?

Only time will show .-)

  ¶ 10:53 AM 0 comments

  Patterns: Decorator. A Real life example The book Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma et al, classifies the Decorator pattern as a structural pattern. This pattern offers a flexible alternative to subclass. The main difference between subclassing and the Decorator pattern is this: with subclassing, you work with the class, whereas in the Decorator pattern, you modify objects dynamically. When you extend a class, the change you make to the child class will affect all instances of the child class. With the Decorator pattern, however, you apply changes to each individual object you want to change.

Need a very tangible and real example ?



Car suppliers often attach license plates to framings with their brand name printed on it. This framing, with the plate attached, are then again mounted on the car. In This way everyone can see where you bought your brand new car. If you're real cool you replace it with a custom one, like the one's show here from http://www.autolicenseframes.com

The framing is just a few centimeters wider than the license plate. The license plate fits into the framing. The bolt holes in the frame and the license plate are perfectly aligned with the holes in the car. This can be viewed as the interface or contract.

The framing can therefore be said to comply to this interface and it wraps the license plate. The framing adds functionality (aestethics) to the license plate without modifying it. No subclassing needed, in other words a real life decorator !  ¶ 2:21 AM 0 comments

  Patterns: Factory and Decorator, a powerfull combination Introduction

While working on a system that distributes passwords throgh different communication channles (email, SMS, snailmail etc) I noticed that the sloppy programmer (hired consultant ofcourse) had written the system with no audit logging what-so-ever.

Since the system had a fair general design, I figured out that adding logging, transparently to clients, without having to change the implementation should possible.

The old design

An interface called Distributor, and a set of implementations are the main point of interest. The Distributor interface declares one method called distribute. All concrete distributors implement this method.

A DistributionFactory class creates implementation clases based on an input parameter holding customer information. The business rules are not really important in this case so I've removed the argument to the constructor for simplicity

Exploring alternatives

The easiest way out here is of course to just go ahed and implement audit logging in all the Distributor implementations. Of course, this would be a violation of the DRY principle.

At one point I was tempted to create a Template. This would require me to create an abstract base class for all distributors with an abstract method called handleDistribution (or something similar)

I would then have had to modify all distributors and rename the method that implemented the functionality to handleDistribution, and of course implement the distribute (in the abstract base class) so that it would first call handledistribution, and then do logging later

The total impact of this would have been

• No Change in the factory class, that's great!
• Code changes in all distributors. Modify to extends the parent class. Not so great!
• Rename of one method in every distributor. Not so great!
• Create one new abstract base class with the template code. Not so great!

Using a Decorator



A real elegant solution is introducing a Decorator. The Decorator class conforms to the exising Distributor interface. The Decorator in this case is called LoggingDistributor

The LoggingDistributor takes a Distributor as an argument in the constructor, and impelments the distribute method by delegating the method calls to that actual instance. After
the delagation, it logs the event.

Conclusion

I was very satisified with this design, since it enabled me to change the system with minimal impact on the existing code. Only the Factory class is modified, and only one class added.

I think this is a great example, outside the GUI world, on how the Decorator and Factory pattern together can be very usefull in adding functionality to an existing system causing a minimal amound of modification.

source code available here

  ¶ 1:40 AM 2 comments