Critiquing the GOF cataloquing technique for Abstract Factory design pattern

This lecture’s tasks were:

Task1:

Selecting any one to the GOF Design patterns; and criticizing its cataloguing technique.

Below I criticise the GOF cataloguing technique of the Abstract Factory design pattern.


The Abstract Factory has been catalogued consisting of the following elements; Name, Intent, Also Known As, Motivation, Applicability, Structure, Participants, Collaborations, Consequences, Implementation, Sample Code, Knows Use, and Related Patterns.

This cataloguing technique gives a birds view of what the pattern is about, what it does and results of using the pattern. Such detailed information gives confidence to the user as all the information they need about the pattern is available.

Further it save the designer time as they would know how and where to apply the pattern rather than finding out such information from scratch.

By giving the applicability of the pattern further reassures the pattern user that the pattern under consideration will produce the results it claims to yield, and that the pattern has be used and proven to work.

The Consequence element in cataloguing the pattern is quite useful, since it adequately addresses the trade offs or benefits of using the pattern before it is used. Therefore the user is given a chance to carefully weigh the usage of the pattern.

While as the cataloguing technique has the above advantages, it does not come without flaws. Below are some of the disadvantages of the cataloguing technique of Abstract Factory.

The GOF have argued that the name of a pattern should be unique. That is a pattern is solely known by one name only. However, including the Also Known As element in the cataloguing technique compromises the uniqueness of a pattern name.

By explicitly showing where the pattern is used can reduce the designer innovativeness as they may not take time to think of new and better situations in which to apply the pattern. Designer may restrict themselves to applying the pattern to only known uses.

Since the Structure of the pattern is given; especially in form of a UML diagram, there seemed to be no need to further give a sample code for the pattern. This code may be left out as it can be worked out from supplied UML diagram. Users are given a choice to implement/ code the pattern in any language of their choice - of course an Object Oriented language. This removes the fuss of having the code the same pattern in say Java, Smalltalk, C++ and others.

The inclusion of Motivation and Applicability in the cataloguing technique is irrelevant. The Applicability section includes situation in which the pattern is usable and also represents the context part of the pattern. The Motivation section on the other hand provides a scenario which consists of a problem and a context in which the pattern can be used. This two elements can therefore be shown as one, that is either as Applicability or Motivation.


Task 2:

This task requires finding out one other Design Pattern apart from those supplied by the GOF


Typed Links Design Pattern

This is one of the MobileUI Design Patterns developed by Patterns in Interaction Design, www.welie.com. The Patterns in Interaction Design catalogue their patterns as: Problem, Context. Solution; Rationale; Example; and Known Uses.

The Typed Links Design Pattern with its elements.

Problem:
Users need to know what they are selecting

Context:

Since WML only has links there is no way to tell whether the link is used to go down a hierarchy or a link to a real service or a link that leads out of the portal.

Solution:
Use special prefixes to distinguish several types of links.
Use a prefixed link to indicate the type of the link. A "+" can be used to indicate a category, a ">" to indicate that it is an outgoing link. Other types may include payments or help.

Rationale:
The prefix shows meta information about the link destination. The meta information, even unconsciously, helps users to understand what they are doing.

Example:
To show a category a "+" is used and to show an outgoing link a ">" is used.

Knows uses: wap.tutch.nl

www.welie.com.

Software Patterns

What software engineering?

Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software.[1]

Software engineering applies both computer science and engineering principles and practices to the creation, operation, and maintenance of software systems. It therefore covers technical and management issues (directing programming teams, scheduling, and budgeting) as of developing software systems.


What is a software pattern?

Software pattern represent a general repeatable solution to a commonly occurring problem in software design. The kind of problem is an engineering problem. Put simply a Software Pattern = (Software engineering Problem + Solution) in a context. Software patterns are not finished designs that can be transformed directly into code. Rather, they are a template for how to solve a problem that can be used in many different situations.


Frequently Asked Question about Software Patterns

1. Is a software pattern different from a pattern?

Yes. Software patterns deal solely with software problems while patterns a solution which can be applied to a reoccurring problem in a specific context. Software patterns apply only in the software designs. On the whole, software patterns are a subclass of patterns.


2. What is the difference between software patterns and

a class?

A software pattern is not an implementation. It simply describes when, why and how to go about creating an implementation or other engineering products. A class is a blueprint from which individual objects are created. Classes are implemented.

List of types of software pattern?

The following are some of the types of software patterns

• Design patterns
• Analysis pattern
• Organisation patterns
• Process patterns
• Domain-specific patterns

3. Do we need software patterns?

Yes, we need. Software patterns help in the following ways.

1. Solve “real life” problems
2. Capture domain expertise
3. Document design decisions and rationale
4. Reuse wisdom and experience of master practitioners
5. Convey expert insight to novices
6. Form a shared vocabulary for problem-solving discussion[2]



[1] http://www.cs.queensu.ca/FAQs/SE/questions.html
[2] http://www.cmcrossroads.com/bradapp/docs/patternsnutshell.html#Pattern_Kinds

http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Lecture 1 - Introduction to Pattern

This lecture was an Introduction to Patterns

How I have understood Patterns

Patterns can be seen as a templates that can be used to solve a specific problem that occurs over and over again in a given context or set of circumstances.

The use of patterns offers tested and proven development paradigms good quality results. In other words and a tested and proven solution to that problem is applied, the resulting solution of good quality since the solution has successfully been used over and over again to solve a specific problem.

Below are the components that make up a pattern.

• Problem
• Context
• Motivation (force)
• Solution
• Examples
• Related patterns
• Known uses
• Pattern name
  

Benefit of using Patterns

The use of pattern speeds up the development process by providing tested and proven development paradigms. Developer therefore spend less time on developing test cases as they are sure that the product will work as expected, since it has been built following a well tested and proved method. However, this is no justification of not developing thorough a test case.

Patterns also reduce the need to redesign a solution to a specific problem. Whenever a problem arises, the already tested and proven solution (pattern) can a apply to it without wasting much time rethinking of a solution

Since patterns provide reusable solutions, they help to reduce costs involved in developing a product or getting solutions to a problem. Few consultants on a project for example may be reduced as provide expertise in solving a specific problem.

Where patterns are well documented/ catalogued, they are useful in passing knowledge from experts to novice.



I have discovered my own pattern!!!!

After the lesson I was able to develop my own pattern to solve. I am currently doing a project in Flash lite 2.0; for the time I have working with Flash Lite 2.0 I have discovered the pattern below.


Pattern name: Flash lite 2.0 tween pattern

Problems:

How do I develop movie player (with play, stop, forward and backward functions) in Flash lite 2.0 without having to study Actionscript 2.0?

Context:

Am developing a movie player in Flash lite 2.0, Among other modules in the application, the User interface module has the following functionalities: Play functions, Stop, Forward, and Backward. ActionScription 2.0 is used to develop these functionalities. I am not a good Actionscript 2.0 programmer and have limited time to ActionScript 2.0.

Solution:

Place each function (play, stop, forward and backward) in a separate frame on stage and tween all the frame.


References:

http://members.cox.net/risingl1/articles/expertise.htm
Linda Rising
Patterns: A way to reuse expertise
Accessed: 6th February 2007

http://www.tech.port.ac.uk/staffweb/chandlej/patterns/patterns.htm#Using%20a%20Design
Jane Chandler and Steve Hand (20th March 1998)
Introduction to Patterns
Accessed: 6 February 2007


Design Patterns
http://www.dofactory.com/Patterns/Patterns.aspx
Accessed: 6th February 2007

Design Pattern (Computer Science)
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)#Uses
Accessed:6th February 2007