Friday 4 May 2007

BLOG 13 -Conclusion on PAFSD Module

BLOG 13

As the PAFSD module comes to an end as the semester ends, in a nutshell I can say I have learnt a lot and am thinking to apply patterns were applicable to my software engineering project.

In general I now understand what patterns are and are not. Also I now understand clearly how wrong implementation and use of catalogue patterns can lead to bad solutions hence, anti-patterns.

The introductory sections of the module dealt with Christopher Alexander’s ideas of patterns. The main focus of this module was on design patterns by Gang of Four (GoF), the elements of patterns and how to create and catalogue a new pattern using the elements of patterns by Alexander or GoF. In one of my earlier blog, I tried to explain what a design pattern is. The last sessions of this module-lecture covered Anti-patterns. (I also tried to explain Anti-patterns in one of my blogs).

GoF categorized there patterns in three groups:
Creational
Structural
Behavioral

Twenty three (23) patterns fall within these categories. They are summarized below;

Creational Patterns

Abstract Factory
This pattern is used when you want to create an instance of several families of classes.

Builder
This pattern is used when you want to separate object construction from its representation.

Factory Method
This pattern creates an instance of several derived classes.

Prototype
This pattern allows a fully initialized instance to be copied or cloned.

Singleton
This pattern can be applied to a class of which only a single instance can exist.

Structural Patterns

Adapter
This pattern is used when you want to match interfaces of different classes


Bridge
This pattern is used when you want to separates an object’s interface from its implementation

Composite
This pattern is used when you want a tree structure of simple and composite objects

Decorator
This pattern is used when you want to add responsibilities to objects dynamically

Facade
This pattern is used when you want a single class that represents an entire subsystem

Flyweight
This pattern is used when you want a fine-grained instance used for efficient sharing

Proxy
This pattern is used when you want to an object representing another object


Behavioral Patterns

Chain of Responsibility
This pattern is used when you want to find a way of passing a request between a chain of objects

Command
This pattern is used when you want to encapsulate a command request as an object

Interpreter
This pattern is used when you want a way to include language elements in a program

Iterator
This pattern is used when you want to sequentially access the elements of a collection

Mediator
This pattern is used when you want to define simplified communication between classes

Memento
This pattern is used when you want to capture and restore an object's internal state.

Observer
This pattern is used when you want a way of notifying change to a number of classes.

State
This pattern is used when you want to alter an object's behavior when its state changes

Strategy
This pattern is used when you want to encapsulates an algorithm inside a class

Template Method
This pattern is used when you want to defer the exact steps of an algorithm to a subclass

Visitor
This pattern is used when you want to define a new operation to a class without change

Cheers to you all that sent your comments. Thanks a lot and good luck

Wednesday 18 April 2007

Anti-Patterns

BLOG 12

Anti-Patterns

Coincidentally, this topic happens to be task 4 of our coursework, so I won't elaborate more on it on my blogg.In the event the patterns are not applied correctly due to negligence on the part of the developer then the pattern becomes an anti-pattern hence defeating the pattern intended role by it creator. In this light, the pattern will be seen as anti-patterns, anti-patterns are seen as negative solutions that present more problems than they address.Anti-Patterns begin with a compelling, problematic solution.

Once an Anti-Pattern has been correctly identified, its refactored solution can be used to obtain a better convergence of the underlying forces to lead you to a better understanding of the problem and an effective method of resolving the problematic solution. [SWE98]

Anti-patterns can be viewed in three ways according to W.H Brown et al; development anti patterns which comprise technical problems and solutions that are encountered by programmers, architectural anti-patterns which identifies and resolves common problems in how systems are structured and managerial anti-patterns which addresses common problems in software processes and development organizations.In summarizing; Anti-Patterns are used to quickly move from negative situations to positive solutions.

Anti-Patterns are useful for refactoring and reengineering in the computing world.

[SWE98] Anti-Patterns Refactoring Software, Architectures, and Projects in Crisis SWEE ‘98 Hays W. McCormick Lead Engineer, (http://www.antipatterns.com/briefing/sld006.htm ) slide 6

Bridge Pattern

BLOG 11

Bridge Pattern

In real life a bridge is seen or considered as a connecting / intermediate route or phase between two elements or conditions. It provides access from one point to another whether there was none before. You can choose to remove or suspend that access as you choose to.

In design patterns, there exist structural patterns by GoF, the bridge pattern. From my understanding of a bridge pattern since Inheritance binds an implementation to the
Abstraction permanently which makes it difficult to modify, a bridge pattern can be used to decouple the abstraction from its implementation so that it can be modified at anytime and then bridge or coupled again with its implementation to be used at run time. The decoupling helps the abstraction and implementation to be used independently also. GOF in there own words say that the intention for this pattern is to “Decouple an abstraction from its implementation so that the two can vary independently” [GoF]

[GoF] GoF, elements of reusable Object Oriented software, Page 157

Facade Pattern

BLOG 10

Facade Pattern

Inorder for systems to be built efficiently and also managed, the whole system should be structured into sub-systems. Facade helps provide a simple interface to a complex subsystem.

This patterns can be used were there are many dependencies between clients and the implementation classes of an abstraction. This pattern can be used to decouple the subsystem from clients and other subsystems hence promoting subsystem independence and portability.

According to GOF, the intention of this pattern is to “Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.”[GoF]


[GoF] GoF, elements of reusable Object Oriented software, Page 157

Decorator Pattern

BLOG 9

Decorator Pattern

The decorator pattern is a pattern used when u need to add more features to an object. For example in real life, a manufacturer may create a basic car, say a Mercedes Benz C-class. Adding more functionality to the car like added lights, navigation system, big rim, dust pad, CD changer with these actions u are decorating the more.

In GOF own words, a decorator pattern is “Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality” [GoF]

[GoF] GoF, elements of reusable Object Oriented Software e-book page 149

Strategy Pattern

BLOGG 8

Strategy Pattern

At the end of the lectures on strategy patterns, I was able to understand that a strategy pattern provides a way to configure a class with one of many behaviours. Strategy pattern provides an easier way to extend a model to incorporate new behaviours without recoding the application. This pattern may be applied in a situation wherein you need different variants of an algorithm. GOF defined strategy pattern as “Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.” [GoF]

[GoF] GoF, elements of Reusable Object Oriented Software e-book page 266

Adapter pattern

BLOGG 7

Adapter pattern

From my basic understand of adapters, I was able to understand to some extent the adapter pattern too after lectures on adapter patterns. Normal adapter is used as an interface to connect another device that cannot directly fit into the other device. For example; UK made devices uses 3 pin whiles most USA devices uses 2 pin, you definitely cannot connect a three pin device into a 2 pin socket on the wall, in order to do so, you need to get an adapter that is capable of accepting the 3 pin plug to be plugged into it and it has a two pin that can enter the socket on the wall, hence it makes the incompatible device to now work, you can now use the device. There also exist adapters with 3 pins to fix into socket in a wall and has the capability for a two pin plug to fix into itself, hence providing an interface. With this brief introductory explanation of an adapter I will now attend to explain the Adapter pattern by Gang of Four. An adapter pattern creates an interface for different classes and allows them to work together. You can use an adapter pattern in the case you want to use an existing class but it interface doesn’t match the one you need. GOF, they define Adapter Pattern “Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.”

You can have a class and object adapters. An adapter pattern provides a way for clients to use two or more incompatible objects and let them communicate and interact. In general, adapter pattern improves reusability.

I now have considerable understand to what recurring problems to apply adapter pattern in designing object oriented systems.

[GoF] GoF, Elements of Reusable Object Oriented Software e-book page 20

Monday 12 March 2007

Abstract Factory Brief...

27-02-2007 - BLOGG 6

Explain Abstract Factory and what you think about it.

An abstract factory provides an interface for creating families of related or dependent objects without specifying there concrete classes. [GOF]

I basically think that an abstract factory pattern tries to present an abstract class from which several other inherited classes can be derived from.

[GOF] Design patterns- elements of reusable object oriented software, GOF, (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

Review of PAFSD coursework 2006/2007

27-02-2007 - BLOGG 5

Review of PAFSD coursework 2006/2007

I think the course work is very tough, but fair. I do appreciate question 1, and trying to under the question better in order to make a go at it. I do have a doubt about question 2. At the moment I think I understand question 3 which relates to expanding and extending One of Iron’s Temporal Patterns (living site, Incremental Growth, Freshness dates or Unchanging URL’s) into a complete, draft pattern putting one of this pattern into the 13 elements of GOF and question 4 which is to write an essay on anti-patterns based on the quote. I am trying to grasp proper footing in the related topics.

I do appreciate question 5- the bloggs section do give me the opportunity to post out my ideas and let others view and criticize. Also I can learn from others too as it presents an interactive forum to share views and ideas on design patterns ideas.

One extra Design Pattern

20-02-2007 - BLOGG 4

PAFSD Lecturer ask the class to research and note one other design pattern (not within the GOF 23 design patterns).

Name of Pattern:
Module Tab design pattern [5]

Problem
The user needs to navigate through one or more stacked panes of content without refreshing the page.

Applicability: (where and when used)
There are multiple panes of content, but there is space to only show one content pane at a time
The different panes of content do not need to be viewed in context with each other.
You need a way to switch between the content without going to a different page. For navigating to different pages within a site, use Navigation Tabs instead
There are 2-10 category titles
The category titles are relatively short and predictable.

Solution
o Present a single-line row of links immediately above the stacked panes of content they will control.
o Never stack multiple rows of tabs to control a single piece of content.
o Separate the links with the vertical bar character "" or through an equivalent graphic.
o Always show one tab as selected with its content visible
o Indicate the selected tab by highlighting the background of the "cell" around it. Yahoo! adds a "pointer" to the bottom of the selected tab.
o The content should be visually connected to the tab it is associated with and be visually bounded (usually by a box.)
o Only one content area may be visible at a time.
Maintaining the Metaphor
o Tabs should appear in the same location as the user clicks from one tab to another.
o Wherever possible, do not refresh the entire page upon selection of a new tab.
o Selecting a tab will not affect other parts of the page.
o Selecting a tab will not navigate to a different page or perform an action (beyond switching the visible content.
Rationale
o Tabs provide context. They give visual indication of a user's location within a body of information.
o Tabs build on a real world metaphor. The selected state is reinforced with the file folder tab metaphor of a folder physically in front of the others in the set.
o Tabs provide navigation. They provide the ability to navigate alternate content views.
Accessibility
o Allow the user to navigate across the tabs in a logical order with the Tab key.
o A focused tab can be selected with the Enter key.
o Indicate the active tab (pane) by one of these alternative means (in addition to visual indication):
§ Include a TITLE attribute with the word "active" into the link that was just activated.
§ Include an invisible graphic with an ALT attribute and a word "active" into the link.
§ Attach an ALT attribute with the word "active" to Yahoo!'s graphic that indicates active link.

[5] http://developer.yahoo.com/ypatterns/pattern.php?pattern=moduletabs (2006-03-05)
[GOF] Elements of Reusable object Oriented Software, GOF 1998

Design Patterns and Gang of Four (GOF)

LECTURE 3 (20-01-2007) - BLOGG 3

DESIGN PATTERNS


I now have an introductory knowledge of design patterns. In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design.

GOF defined design patterns as “a design pattern names, abstracts and identifies the key aspects of a common design structure that make it useful for creating a reusable objects design. The design pattern identifies the participating classes and instances, there role and collaborations, and the distribution of responsibilities.” [GOF]


TASK 1: (20-10-2007)

Select ONE of GOF Design Patterns out of the 23 design patterns and criticize all its elements

Creational Pattern – Builder Pattern

One of the reason why I chose this pattern for criticism is the fact that this pattern explains that the constructor of a class is outside the class, whiles in java, the constructor is written within the same class. I find it rather a disturbing and conflicting statement.

After careful evaluation of this Pattern from the GOF: Design patterns- elements of reusable object oriented software. I am moved to appreciate the pattern concept.

The builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. [GOF]

[GOF] Design patterns- elements of reusable object oriented software, GOF, (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

If you are to a create a complex object independent of the parts that make up the object then, the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled and also the construction process must allow different representations for the object that is constructed.

The good consequences of builder pattern concepts are that it lets you vary a product's internal representation and also isolates code for construction and representation.

There is a need to catalogue each pattern created so it can be referred to and re-used. GOF created thirteen (13) elements of patterns under which each of the 23 GOF design patterns created is catalogue under.

Elements of patterns

Pattern name and classification
o Builder Pattern; this name uniquely identifies this pattern, this pattern is classified under creational patterns.

Intent
o The intention of this pattern is when complex objects are created, it seperates it’s construction from its representation so that the same construction process can be used to create more different representations.

o In my view I think Intent is a vital element and is necessary at all times when preserving patterns as it tells a user the intentions of the preserved pattern in the catalogue.

Also known as
o Just like humans can have other names, so patterns too.

o I critically think this element is not so necessary. There might be cases when a pattern will not have other known names.

Motivation
o This element presents a problem and the usefulness of the pattern to solve it in a given context.
o I critically think this element is important and must be documented whenever a pattern is been preserved.

Applicability
o This element highlights scenarios (context) areas in which the pattern might be applied to.
o I critically think this element is very important as it deals with the context area from which a problem is coming from.

Structure
o This element shows a pictorial image of the pattern suing class diagrams.
o I critically think this element in very important as a brings forward a comprehensive pictorial view of the pattern.

Participants
o This element shows all assembly parts. i.e. classes and objects used in the pattern.
o I critically think that this element is very vital as it shows all classes and objects and there functions and relationships.

Collaborations
o This element shows basically interaction of classes.
o I critically think that this element is vital as it will help developers to use the patten irrespective of there programming background.

Ø Consequences
o This element shows the resulting effects both positive and negative when this pattern is applied in system design.
o I critically think that this element is very vital as
§ It lets u vary a products internal representation
§ It isolates code for construction and representation
§ It gives you finer control over the construction process.


Implementation
o This element explains how the pattern is implemented, In builder pattern it states that its constructs it products in step by step fashion.
o I critically think that this element is very vital as it aids greatly in implementing the pattern.

Sample code
o In some cases it is not necessary to put a sample code. Can only be necessary to programmers who are working iwith same language in which the code is written.
o I critically think that this can be omitted if necessary, but in cases were there are multiply versions of the same code written in different languages, it will become useful.

Known uses
o Thie element is like a reference, for users to check out areas where the pattern have been implemented before.
o I critically think this element must be included as it shows confirmation that the pattern is actually a proven tested on.

Related Patterns
o This element shows other patterns that are directly linked, or have some relationship to the pattern
o I critically think it not necessary to include this element only in extreme cases were there are close ties between a pattern and the pattern under review.

Wednesday 7 March 2007

SOFTWARE PATTERNS AND FAQ

LECTURE 2 (13-02-2007) – SOFTWARE PATTERNS- BLOGG 2

After lecture 2 – PAFSD, I now have the basic knowledge of what software patterns is and can now define software patterns as an accepted proven solution to solve a recurring software engineering problem in a given context.

Patterns and Software Patterns FAQ’s

Q1. What is a pattern?

Ans: A pattern is a proven accepted solution to solve a recurring problem in a given context. If the context changes even if the problem is the same, then the solution changes too.


Q2. Why applying patterns to software engineering a good idea?

Ans: Benefiting from the knowledge and experience of other people who have put more effort into understanding contexts, forces, and solutions than you have done or want to do. Further, patterns can be more reusable than code, since they can be adapted so that you can build software to address particular special circumstances that cause you to be unable to reuse an existing component.

Q3. What is a software pattern?

Ans: Software patterns can be defined as an accepted proven solution to solve a recurring software engineering problem in a given software engineering context.

Q4. What is not a pattern?

Ans: A general solution to every design problem in a context is not a pattern. Solution to problems in a context that have worked only once is not a pattern.

Q5. Where can software pattern be applied?

Ans: Software patterns can be applied in software engineering development processes.


Q6. What is the difference between software patterns, frameworks, algorithms, and business objects?

Ans: Software patterns can be defined as an accepted proven solution to solve a recurring software engineering problem in a given software engineering context.

Whiles a framework is a set of cooperating classes that make up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes a framework to a particular application by subclassing and composing instances of framework classes. [2]

A pattern is not an implementation. It describes when, why, and how to go about creating an implementation or other engineering product.

An algorithm is basically a formula or set of steps for solving a particular problem.
A pattern describes how and why an algorithm may be apply in a given development context, along with guidance for applying them.

Business objects are objects in an object-oriented computer program that abstract the entities in the domain that the program is written to represent. For example, an order entry program needs to work with concepts such as orders, line items, and invoices and so on. Each of these may be represented by a business object. [3]

Q7. In real life can software patterns be used by both beginners and software specialists alike?

Ans: Software patterns can be used by both beginners and software specialists alike as it is said, if there is a proven software engineering solution to a problem in a given context, why not use it rather than creating the wheel. (Finding the solution to the problem from scratch may be a waste of time.

Q8. What is anti-pattern?

Ans: Anti-Pattern are Negative solutions that present more problems than they address. [4] A well formulated Anti-Pattern also tells why the bad solution looks attractive.



References:
[2] http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html#TOC_PatternElements#TOC_PatternElements 14/02/2000


[3] http://en.wikipedia.org/wiki/Business_object_(computer_science) 07:43, 5 October 2006

[4] http://www.antipatterns.com/briefing/sld003.htm, AntiPatterns :Refactoring software architectures, and projects in crisis SWEE 98 hays w. Mc Cormick

Saturday 10 February 2007

Patterns and Example

At my first Patterns for software design (PAFSD) class on 06-02-2007, Our lecturer, Dr. Sri introduced us to Patterns generally.

In Christopher Alexander's own words "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that you can use this solution a million times over, without ever doing it the same way twice." [1]

[1] Christopher Alexander, A Pattern Language: Towns/Buildings/Construction, 1977, New York: Oxford University Press.

From the description given, a good pattern can be said to be a proven accepted solution to solve a recurring problem in a given context. If the context changes even if the problem is the same, then the solution changes too. The solution has to be appropriate to solve the current problem in the given context in order for it to be accepted as a good pattern.

Example of a Pattern.

Name: Teaching mentally retarded kids how to read music notes.

Problem: How to teach a mentally retarded kid how to read music notes easily?

Context: Teaching young kids how to write and read music is tedious. So teaching mental retarded is even much more difficult.

Mentally retarded kids find it diificult to remember things they are taught. .

Solution: start by teaching how to read the abc's of music. (i.e do, ra, me fa, so, la, ti do) go extremely slowly ensuring that the kid grasp each note in the trend before moving to next. Use exhaustive repetition to ensure what been taught sinks well and resides in the kid, as they easily forget.