Design Patterns

Friday, May 19, 2006

Behavioral Patterns continued -Lecture 8

Observer pattern

This pattern lets all the objects who are registered with it, know about any changes that happen immediately. its more of a one to many relationship between objects. A practical example of the observer is the way the news stations work with their reporters. In an event when something happens in the country that concerns its citizen, e.g war news, they braodcast the news to all the citizens in the country through T.V and radio almost immediately.

Visitor pattern

Visitor allows an operation to be carried on an object structure without changing the classes of the the elements on which it operates on. This means that, take for example while you are surfing on the web, there are pop up adverts that come on your screen whilst it allows you to continue with what ever you were doing. These are called intelligent agents

Reference:

Eric Freeman and Elizabeth Freeman with Kathy Sierra & Bert Bates (2004) Head First Design Patterns pg 638

Thursday, May 18, 2006

Behavioral Patterns -lecture 8

Behavioral patterns focus more on the way objects and classes communicate among themselves, but in a small way also deal with algorithms and the assignment of responsibilities between objects.
There are in total 11 behavioral patterns namely; visitor, template, chain of responsibility, iterator, state, mediator, momento, strategy, observer, command and interpretor.

Unlike in the creational and structural patterns where the either inheritance or composition, behavioral patterns have divided them selves up with some using encapsulation, others composition and inheritance, for example, template uses inheritance, chain of responsibility uses composition and encapsulation is used by the visitor.

chain of responsibility
it does not support the coupling of the sender and receiver objects but instead it gives more than one object the chance of handling the request. this request is passed on from one object to another until it finds the one suitable to handle the request.

This pattern is used in cases where a request is sent out to many objetcs without specifying the receiver explicitly.

Reference:
Gamma, E., Helm, R., Johnson R., & Vlissides, J. (1994) Design Patterns: elements of reusable software, Addison Wesley, ("Gang of Four Book (GoF)") pg 395

Wednesday, May 17, 2006

Lecture 7 :14 March 2006

Structural Patterns

Structural patterns deal with the composition of larger structures among objects and classes. Utilisation of inheritance is a common feature used in structural class patterns in the composition of intrefaces and in implementation.
There are 7 structural patterns namely; proxy, decorator, composite, flyweight, Facade, Adapter and bridge.

Adapter
This pattern brings together two different interfaces together due to incompatibility, and its put in an interface the client expects.

Take an example of a household adapter, it will accept a two pin plug so that it goes into the three pin socket in the wall. The adapter facilitates for the connectivity of these two diffeent interfaces which are not incompatile to communicate/work together.
The adapter will prove useful when you want to make a class that don't relate/match to the one required(incompatibility)
One of the consequences that may arise is that it may take over the attributes of the adaptee as it will be a subclass of the adapter.
The adapter can be likened to the bridge pattern.

Decorator
Its a pattern that gives extra reaponsibilities to an object dynamically. Instead of always using subclassing for extension of fuctions, the decorator can be used as an alternative to subclassing.
The decorator is suitable for use in situations where you do not want to affect the other objects, by adding responsibilities to the one object.

Bridge
This pattern separates the abstraction from its implementation in order for the two to vary independently.
Its mostly used in situations where you do need permanent bonding of the implementation and abstraction. The bridge pattern encourange the improvement of extensibility as it can be done independently. Lastly the process in the abstraction and implementation are hidden from the client.

Composite
It composes objects in a tree structure and presents them as part-whole hierarchies, which composes of the leaf, the composite and the component. All the objects are treated uniformily in the composite. The composite also supports easy extensibility.

Flyweight - effective management of huge numbers of objects through sharing

Proxy - its an object that is acting on behalf of another object to control access

Facade - provides a single object representing the whole system.

References:

Gamma, E., Helm, R., Johnson R., & Vlissides, J. (1994) Design Patterns: elements of reusable software, Addison Wesley, ("Gang of Four Book (GoF)") pg 395






Saturday, May 13, 2006

lecture 5 & 6: March 2006
Continuation of Creational patterns

Buider , prototype, Singleton and Factory Method Design patterns

Buider Design Pattern is used in the creation of a very complex object, though the representation is hidden from the client. The same process used in the creation of the object can be used again in the creation of other objects.
Take the Bicycle Assembly plant ,for example. Such a plant uses the buider pattern in the construction of of its bicycles, as there are different parts which make up a bicycle, such as tyres, sadle, peddle etc. even if the parts and the process used in the creation of the bicycles are the same, there are different types of bicycles that they also make such as Mountain bikes , sporting bikes and ordinary bikes.

The buider is a good pattern because it supports modularity, in the building of complex objects, and modlarity has various advantages including the ease of debugging.


Factory method provides an option to choose(choice) to the subclasses of the objects to institiate at runtime. factory does not have a family of products like the abstract factory.

Prototype
Its a pattern that uses the theory of "Copy and paste", i.e. it creates new objects by copying/cloning after specifying the kind of object to be created. The catch is that the objects to be cloned should be similar, that you dont have to create all the time. it behaves like a template, for example a college will have the same letter for enrolment for all students with the difference being the date and the name of the student. But the same letter is copied for the next student who wants the letter.

Singleton
a class of which only a single instance can exist.An example of a singleton would be, in the real world situation,take in a soccer match, a goal post will only be managed by a single goal keeper for a match.
The singleton will work very well in a stand alone environment but might prove to be mulfanctioning in the even when it is incorporated with other programs.

further reading: www.dofactory.com/Patterns/Patterns.aspx


References:

Gamma, E., Helm, R., Johnson R., & Vlissides, J. (1995) Design Patterns: elements of reusable software, Addison Wesley, ("Gang of Four Book (GoF)") pg 97 - 134

Tuesday, May 09, 2006

Lecture 4: 2nd March 2006

Creational Patterns - Abstract Factory

Creational Patterns consists of abstract factory, prototype, singleton, factory method and Buider patterns.
Creational patterns have been classified under creational because they create objects at runtime. An example of when you can see a creational pattern in action with the creation of an object at runtime is when you , take a juke box. Once money has been inserted in the machine and the desired song selected, only then will the machine play the music desired.

On this particular day, we started off with the Abstract Factory.

Abstract Factory, is a design pattern that is administered to objects which are closely related in a family or are very dependant of one another in the creation of objects without specifying concreate classes at runtime.An abstract interface is given to the client and hiding the controlling mechanism, or process that are in the concrete classes from the client. [1]

Since the objects of the AbstractFactory are closely related, one of the problems of implementing this is that, it becames difficult to add new products to the abstract factory and entiles changing the whole structure, subclasses and the abstract classes. its one of the disadvantages of this design pattern[2]


References

[1]Eric and Elizabeth Freeman with Karthy sierra and Bert Bates, 2004, Head First design patterns, pg 156, ISBN:0-596-00712-4
[2] Eric and Elizabeth Freeman with Karthy sierra and Bert Bates, 2004, Head First Design Patterns, Pg 159, ISBN:0-596-00712-4

Monday, May 08, 2006

Lecture 3: 28th february 2006

Jane Chandler's visit to St.Patricks College

This was one important day because we had a visit from our Unit Coordinator from the University of Porthmouth, Jane Chandler.
Most of the students i talked to really said it was "patterns made simple" when jane explained what patterns was all about. We were given an extract from Christopher Alexanders "A pattern Language" book and divided into groups to do an execise on using patterns in architecture and come up with the best solutions. Apart frrom that, we were also given a catalogue, "A Pattern Language" to help them with the exercise at hand

On the same day, the course work was handed out to the class. The class and Jane skimmed through the coursework and what the requirements were for each question and if there were any misunderstandings, she made sure each person was clear on what to do. i received my coursework the following day, and most of it was "Greek"

Thursday, May 04, 2006

Lecture 2 :Tuesday, 21 february 2006

Group Dynamics

Most of the day , we did presentations of the group research work we were tasked to do the previous week. My group presentated on the Patterns Vs Packages in all angles, .i.e. definations, advantages, disadvantages, common uses, similarities and major differences of the two. At the time we started researching on packages, we had greatly researched on Software packages instead of packages in general and had to start all over again. within the group we divided 3 people to research on packages and the other three to research on Patterns. I researched on patterns and the following were my findings:

Design Patterns refer to the concept of being able to use the design solution to a recuring problem in a given context. we encounter many problems that have occurred and will occur again, and in such an instance Design Patterns will come in handy.
The advantages of using design patterns are;

  • Design patterns capture design expertise and allow that expertse to be communicated , e.g novice programmer
  • Because design patterns promote design reuse, their is improved quality as a result of thorough testing , hence no mistakes
  • improves documentation and understandability
  • it reduces maintenance costs
  • it acts as a template
  • Design Patterns are extensible , i.e. you can modify it to meet your needs[3][1].

With Design patterns, they are neither code, nor designs, as they must be instatiated and applied. the engineer sholud have an understanding of the imapct of using the design pattern, decision making on on how best to apply the design pattern and lastly implement the design pattern into the code of any suitable object oriented language.

Later on in the day, after all the group presentations, we were told to write a paper on our personnal experience with design patterns, whether we thought it will be useful for software development.

My answer to that question was yes, i thought the design patterns were useful based on the advantages i have listed above. In addition to the listed advantages above , design patterns promote discussion among programmers about known design patterns, that results in more collaboration, knowledge and wisdom combination. Because of this, they facilitate less arguments among developers over different solutions to a problem but focus on thinking of the same solution in different ways.[2]

with that personal view on design patterns, we called it a day.

References;

[1]Mark Grand, 2002, Patterns in Java, vol 1, second edition, a catalogue of reusable design patterns illustrated with UML

[2]Gamma, E., Helm, R., Johnson R., & Vlissides, J. (1995) Design Patterns: elements of reusable software, Addison Wesley, ("Gang of Four Book (GoF)") pg 2

[3]Design Patterns:

http://www.cs.puedue.edu/homes/jv/510s05/patterns.pdf

(Accessed:17/02/06)