Lecture 9: Pedagogical and Anti Patterns 30/04/07

Only two students including myself turned up for this lecture. I think this was due to the fact the dissertation was due at the end of the week.

The lecture started later than planned as we were waiting for other students to turn up. We acted out a writers workshop between the three of us. It was quite difficult to carry it out as it was just the two of us. The writers workshop did not take as long as it should because of the numbers but I could an idea of what is requited from the moderator, the author and attendees of a writers workshop.

During the lecture we also had a brief look at Pedagogical Patterns and AntiPatterns. I found Pedagogical pattern a little harder to wrap my head around. I found it easier to understand when I think about it as a pattern that guides teachers and students. The passing down of wisdom from experienced teachers.

Lecture 8: Writing Patterns

This lecture focused on how patterns are written. Our lecturer explained how organisations such as PLOP hold writer's workshop.

These workshops seem to be carefully organised, ensuring that both the authors of the patterns and moderators get the best out of the workshop. However, I think its a disadvantage to the author of the pattern that the size of the workshop is quite limited. The author might not be able to utilize the full benefit of the workshop.

I understand that a lot of people are not allowed in the workshops, to avoid overcrowding and there might be a need to dispense non -authors evenly among other workshops that might be going on. It might be a good idea to list the patterns discussed in the workshops on the organisation's (such as PLOP) website and linking a forum to it, which the authors and non-authors can discuss the pattern put forward.

During the lecture we had a go at writing patterns ourselves. Our lecturer suggested that we write a pattern on any topic of our choice. The pattern was written in the Gang of Four format. I find it easier writing in the GoF format rather than Alexander. The GoF format appeals more to myself because I feel it has better structure and each information entered in every section from the Pattern Name through to Related Patterns were clear and precise.

Lecture 7: Pattern Catalogues

We had a look at some pattern books during this lecture, this was just to get an idea of the number of patterns available or rather documented. I had no idea that therewere just a vast amount, too much to through individually during the lecture.

Our lecturer decided we should go through as many books as possible and looking up patterns or information stands out to us. I went through about 3 books at detail and discovered the following abouyt them.

The Pattern Almanac 2000 by Linda Rising

This book can be considered a s a reference to all widely published patterns and patter collections. It includes a comprensive index of patterns, pattern collections, authors and citations.

Enterprise Solution Patterns using Microsoft .NET

I found this book more interesting, this was probably due to the fact that I had no idea that they were patterns for deployment of any application, imagine my surprise to learn that there was were patterns for deployment on an Enterprise scale. This book had collection of patterns for web presentation, deployment, distributed systems, services, performance and reliability. The pattern i focused on were the deployment patterns.

I reading up the Layered Application pattern I discovered how to structure an application to support operational requirements such as scalability and reusability. This gave me an idea on how I could apply this in m y final year dissertation.

Pattern Hatching by John Vlissides

This book suggested discusses what is a pattern and why people get confused when labelling a pattern. A pattern must be recurrence (making solution relevant outside the immediate one), teaching (understanding to tailor the solution to a variant of the problem) and named. According to Vlissides, a popular misconception is that patterns are rules (programming tricks) that could be applied mindlessly. This is should not the case at all.

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.