First Blog - A look at Strategy Patterns

This is my first blog for the Patterns for Software Design unit. I decided to have a closer look at the coursework handed out last Monday during the lecture and I also had a closer look at strategy patterns using the Head First Patterns Design book.

I found this topic very interesting because it got me thinking about program design from a different point of view. The main design principles i found challenging were:

1. Identifying the aspects or parts of my application that might vary and separate them from what stays the same os that I could later alter these parts that vary without affecting those that don't - Previously when I designed an application, when ever I drew up the UML diagram, I always took inheritance and OO in general, into consideration but never really gave much thought to the relevance of making my system as flexible as possible, encapsulating parts that might change, with maintenance in mind. Well, I sometimes thought about maintenance but only to an extent, I was mostly satisfied with making sure the user requirements were met. I have come to the realisation that this is not enough because if anything is certain with software development, it is that requirements always change and an application designed well should be able to cope with certain changes.
2. An aspect I can own up to is that it never crossed my mind during the design phase to favour composition over inheritance. I have in the past chosen composition over inheritance but I did this during the implementation phase when i run into trouble trying to make change an object behaviour at runtime.

It seems like patterns could be looked at as a language that application designers could use when describing the design of an application. The developer could have a look at the pattern and know what the designer wanted. This cuts down on the need of a developer having to chase up the designer because some ambiguity occurs with the design.