Lecture 6: Decorator, Composite and Facade patterns

This week lecture was on decorator, composite and facade patterns. This was the last lecture before the Easter break as therewould be no lecture on the 26th March. We are met to use the time for the lecture to work on our portfolio.

Decorator

Head First Design Patterns book uses the example of a system used in a coffee shop. The coffee shop expands with time and additional functionalities are needed to be added to system such adding the price for additional condiments (soy, mocha). The decorator is a design pattern that allows additional behaviour/functionalities to be added to this coffee shop system. I think this a very important pattern because one thing that we can definately be sure of regarding software development is that user requirements always change with time. The head first book described the decorator pattern as a pattern that "attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending fuctionality".

During the lecture we also discussed how decorators are open for extension of responsibilities but closed for modificiation (of existing code) to meet changing requirements. I think it is also worth it to note that inheritance, usually considered as a form of extension might not probably be the best way to achieve flexibility in designs. Decorators act as wrappers, wrapping a component with any numbers of decorators, increaing functionality.

Composite

The composite pattern is used a collection of objects with whole-part relationships(for instance, a text editor has several parts like scroll bars, buttons but it is generally considered as whole) exists and there is a need to treat these objects uniformly. The difference between the composition of objects and individual objects are deliberately ignored. Data structures came up as a good example of composite pattern being implemented. Appyling a structure such any of the various types binary search tree, we would have a structure of an object that contains both compositions of objects and individual objects as nodes.

I learnt that the difference between composite and decorator is not in the structure but it is in the implmentation as one can put one composite object into another. Visitor patterns could be applied to composite patterns to add new functionalities to objects as well as the iterator pattern search through composite objects.

Facade

Head First describe the Facade pattern as a pattern that "provides a unified interface to a set of interfaces in a subsystem.. Facade defines a higher level interface that makes the subsystem easier to use". This pattern is useful if you want to run parts of your system as a subsystem. The example used in the Head first book is a collection of classes for a home entertainment system. Facade passes request on to other classes such as the dvd player class without making changes to the other classes. A client could interact directly with the server classes, while an adapter is needed and should be present for two server classes to interact. I believe changes could be made to one of the server classes without the other classes being affected as the whole system is treated as a subsystem.

Facade pattern provides an interface to interact with the whole system. However, an advantage that Facade has over adapter pattern is that the interface of the facade pattern does not always have to be used.

LINKS

• Java World: A look at the Compsite design pattern
• OnJava.com: Using the Decorator Pattern
• Wikipedia: Decorator pattern
• Wikipedia: Facade pattern

Lecture 5: Visitor Patterns

The lecture this week had to be cut short because our lecturer was feeling under the weather, hopefully she gets better soon.

We did manage to look at the visitors pattern in greater detail from when we looked at it yesterday. It became apparent that some thought is required before the visitor pattern is implemented as it is a trade off between adding additional functionality and increase the number of classes in an application. It appears that the visitor pattern cuts down the work of the designer and developer because implementing this pattern requires the addition of new behaviours in one place, the visitor class. Our lecturer also gave an excellent example of when a visitor could be used injunction with an iterator.

The java world website shows a good example on how to cut out a huge list of if-else statements by implementing the visitor pattern while iterating through a collection.

http://www.javaworld.com/javatips/jw-javatip98_p.html

Lecture 4 (Addapter, Factory Method and Iterator)

I was abit late for the lecture this and was surprised to see that the lecture had been moved to the postgraduate common room.

I think this turned out to be a positive move as we were to talk freely amongst ourselves about our ideas of the Factory method, Iterator and Adapter patterns. This might be because the design of the common room was better than the lecture room and induced a better atmosphere or it could be because of the number of students present.

I missed the discussion on the Factory method however I had a look at kester's blog and I was able to able to catch up on some points that were raised during the lecture. The Adapter pattern was interesting, it is amazing the amount examples available out there in terms of software development. The Iterator pattern is one we have used a number of times in a second year programming unit, I had no idea that we were actually implementing a pattern we using iterator to go through objects in an array for instance.

Looking at the Decorator pattern for the coursework, i had afew problems trying to understand how and when to actually implement this particular pattern. It helped when I started thinking of the decorator pattern as a "wrapper" which aids attaching additional function or responsibilities to an object dynamically.

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.