Ricky Yim walks us through a billing application, in which he uses a combination of the Decorator, and Command patterns to enable easy software maintenance. Is this a good solution to the problem, or would you opt for a rules engine, or something else?

Summary

One of the characteristics of software maintenance is having historical or other constraints imposed on your development approaches. This article shows the technique of applying two very popular patterns, Decorator and Command, in the context of maintaining a billing application. This technique assists in overcoming such constraints, while helping maintain business logic in a modular, transparent, and highly testable manner.

Read Let decorated Commands take over

cool. tasteless decorators now allow us to give our commando pattern a breezy laura ashley pastel-print styling after they complete successful execution on the russian factory.*

*russian factory only makes left shoes, it is more efficient.

in all seriousness, a useful pattern set to keep in handy.

I have used just this approach recently, and it worked extremely well. I'd definately use it again.

That's a very good example of applying the decorator pattern! It exactly emphasises what this pattern is to be used for:

Extending a class' functionality without changing that class.

Regard,
    Dirk

However, without a proper factory this is rather an antipattern, as you have to change all code that uses the calculator. That's not what I call maintainability...

  -Markus

Well, this is where the AOP'lers jump in. Taxes are a cross-cutting concern (as anyone will agree) and should thus be applied declaratively from outside the class. Neither the class nor its clients will notice.

com.company.Calculator.calculate *= 1.1

:-) Matthias

Well, this is where the AOP'lers jump in. Taxes are a cross-cutting concern (as anyone will agree) and should thus be applied declaratively from outside the class. Neither the class nor its clients will notice.com.company.Calculator.calculate *= 1.1:-) Matthias

Yes, the article does point it out:

Better means of achieving these outcomes may be available through aspect frameworks, containers, and so on, but sometimes your maintenance constraints may prohibit their adoption.

:-) José