Friday, 23 March 2007

Description of Gang of Four Patterns

Gang of Four Patterns

In the last lecture I learned about the Gang of Four patterns and I was able to get a brief knowledge about the 23 three patterns involved. In the is 23 patterns I would like to elaborate on one of the patterns in to depth it is the Abstract Factory Pattern

Name
Abstract Factory provides an interface for common and related objects without specifying their classes.

Intent
Converts the interface of a class into another interface clients expect. Adapter lets classes work together.

Known As
Abstract Factory is also known as a Kit

Motivation
Cannot use a toolkit or a class library , because the interface may differ to the required interface of the application.
Library interface cannot be changed without the source code.
A Library cannot be changed for each particular application.

Structure
Multiple Inheritances is used by a class adapter to communicate from one interface to another

Applicability
Can be applicable in an existing class, when the particular interfaced doesn’t suite with one required. Applicable to create reusable classes which can retaliate with uncommon class and unsuitable interfaces

Participants
Abstract Factory
Key role of establishing interface which functions to create objects of abstract product.

Concrete Factory
Establishes the functions to create objects of concrete product

Abstract Product
Establishes an interface to product object

Concrete Product
Describes a product object which will be created by the particular concrete factory

Client
Can use the interface defined by classes of abstract factory and Abstract Product

Collaborations
An instance of a concrete factory is created at runtime.
A concrete factory creates product objects which have implementation. A client should use different concrete factory to create different product objects.

Consequences
Classes created by an application are continued by the Abstract Factory. It is responsible for the encapsulation and creating of product objects. Clients are not involved in abstract interfaces. Product classes’ names are not involved in implementing concrete factory

Exchanging of product families is made easy, because a class of a concrete factory appear only once in an application.
This makes a concrete factory of applications changeable at anytime.
Can use different configurations by changing the concrete factory. Product objects designed in an abstract factory working together.

Implementation
Creating products
Defining extensible factories.

Sample Code
This element illustrates a sample of a source code how a Adapter Pattern can be applied practically to a problem

Known Uses
Windows Applications,
Creation of Scrollbars, Menus, Submenus, Buttons etc.
Business Applications, to create required applications e.g. click events

Related Patterns
Singletons – a concrete factory.



Research of an Intergrated Pattern

Enterprise Integration Pattern by Gregor Hope and Bobby Woolf

What are Enterprise Integration Patterns?
Enterprise integration is a complex field, and there is no simple 'cookbook' answer. That's why patterns are a useful way to convey experience that usually only lives in architects' heads. Patterns are accepted solutions to recurring problems within a given context. They are abstract enough to apply to most integration technologies, but specific enough to provide hands-on guidance to designers and architects. Patterns also provide a vocabulary for developers to efficiently describe their solution.
Who can use Enterprise Integration Patterns?
Most of the patterns assume a basic familiarity with messaging architectures. However, the patterns are not tied to a specific implementation. So if you use EAI suites such as IBM Web Sphere MQ, TIBCO, Vitria, See Beyond, Web Methods etc., messaging specifications such as JMS, or Web service standards like SOAP, these patterns help you design better integration solutions. In some cases, a pattern may already be embedded in the middleware package. This is a sign that the vendor recognized the recurring problem and incorporated the solution into the package. We still present these patterns for two reasons. First, not all packages implement the same patterns, so a user working with another package will still find the pattern useful. Second, despite the default implementation of the pattern in the middleware package, a description of the forces and alternatives is insightful for any architect or developer who is interested in EAI concepts beyond the specific package implementation.
The Patterns
We have identified 65 patterns so far. Which is organized the patterns into the following categories:
Integration Styles document different ways applications can be integrated. These patterns present somewhat of a historical account of integration technologies.
Channel Patterns describe the fundamental attributes of a messaging system. These patterns are implemented by most commercial messaging systems. This section focuses on the interrelationships between different features and highlights implementation trade-off made by different vendors.
Message Construction Patterns describe the intent, form and content of the messages that travel across the messaging system. Routing Patterns discuss mechanisms to direct messages from a sender to the correct receiver. Message routing patterns consume messages from one channel and republish the message to another channel that is determined by a varying set of conditions. The message content is not modified.
Transformation Patterns change the information content of a message. In many cases, a message format needs to be changed due to different data formats used by the sending and the receiving system. Data may have to be added, taken away or existing data may have to be rearranged.
Endpoint Patterns describe the behavior of messaging system clients. They illustrate different ways in which applications can produce or consume messages.
System Management Patterns provide the tools to keep a complex message-based system running. A message-based integration solution can process thousands or even millions of messages in a day. Messages are generated, routed, transformed and consumed. The solution has to deal with error conditions, performance bottlenecks and changes in the participating systems. Message management patterns address these requirements.

Patterns for Software Design Portfolio – 2006/07 Coursework

Patterns for Software Design Portfolio – 2006/07

PAFSD (Patterns for software design) coursework for the current final year students of BSc (HONS) Computing and Information Systems contains of five tasks which is divided as to the following criteria

Task 1 – Design
Task 2 – Programming
Task 3 – Patterns Techniques
Task 4 – Theoretical view of Patterns and criticism
Task 5- Blogs and comments among pattern users.

My intent and decision is to work on Tasks 1,2,4,5 where there is an option of choosing four of the five tasks.

Task 1
According to my view Task 1 is mainly aiming towards the Designing part of Patterns where we will be required to illustrate the given scenario in the form of UML diagrams.
The main UML diagram requested by the coordinator is Class Diagrams which one of the popular ones amongst other UML Diagrams.
Marks allocated to this Task are 25 to obtain a good mark in this task a good knowledge of Object Oriented Concepts and UML Diagrams is essential especially class diagrams.

Task 2
This task is mainly aiming towards the programming and coding part of Patterns where we are required to apply the patterns that we have learnt practically in the means of source code. This task is looks to be simple task than the task 1, but good knowledge of Object Oriented Programming Language is essential either JAVA or C++

Task 3

This section mainly aims towards the technical side of patterns where we are required to provide solutions to an existing problem that was tried to be solved by another pattern technique but failed to do so. We are asked to solve the particular approach by using Gang of Patterns. To be successful in this task a good idea of the elements involved in each 23 GOF patterns is essentials

Task 5
This task is one the easiest task out all the task where 25 marks is gettable this tasks is mainly towards exchanging idea, view, and comments among individuals who use patterns and have clear understanding of design patterns. We are required to upload 12 blogs in this task in which 8 best blogs will be sorted out for marking. Each Blog contains of different sections of Design Patterns that are thought on weekly lecture.

Thursday, 1 March 2007

FAQs on Patterns

Name – Thilebhan Ratnam
Student ID – 97634
Subject: Patterns for Software Designs

What are patterns?


Patterns are solutions for reoccurring problems that are seen over and over again in our environment and its surroundings. It also describes us about the solutions that’s should be adapted to the aroused problems and the main beneficial thing is that these solutions can be used over and over again for many similar problems. In simple words patterns are said to be reusable.
Patterns are also known as communications patterns because they can interact and communicate between different objects
Patterns can exist at many levels of an object from a basic level to generalized and complicated level areas.

What do you mean by software patterns?

Software patterns are reoccurring solutions to software problems that occur in software development over and over. Software patterns constitutive a set of rules describing how to accomplish certain tasks in software development.
Software patterns also help to draw analogies to architecture and logics. It interacts between objects, therefore it’s known as communication patterns.
Software patterns deals with object communication strategies for object inheritance and containment. It is the software of simple that makes methods of interaction to many Rother patterns that is so important.
Software patterns can exist at many levels, from very low specific solutions to a broadly complicated system issue.

What kind of benefits that can be gained from software patterns?

Its is reusable can be used again to different similar problems
Takes less no of time to solve a problem
Provides many solutions to a particular problem

How is a software patterns important to software developers?

Software patterns are important to software development by helping to separate classes and prevent them from having to know too much about one another.
Software patterns help to avoid reinventing the wheels and allow describing programming approaches in terms in which programmes can easily understand.
Software patterns is one of the key components of software development that describes how objects communicate without becoming entangled in each others data models and methods which leads to be a good objective of object oriented programming.
The other aspect in which software pattern is important is by organisation of objects which helps programs to be easily written and modified which will also help programmers to make programming make much easier by following solutions of software patterns.

How can software patterns affect the quality and usability of software?

Software which has been development with solutions of software patterns will be stable software developed using object oriented approaches which will be elegant, easy to use and main table to common solutions encounter in programming challenges
Software patterns build a strong communication between objects to make programming easy to programmers.
Software patterns are part of writing good critical programs; they provide solutions as easy ways to write very professional looking programs and systems.
Software patterns recommend different types of solutions to improve the quality of programming thus enabling elegance and making concrete and believable.
Software patterns provides simple decision making clauses that returns one of the several possible subclasses, which can be reused over and over, and provides solutions that can be utilised in several related objects

Thursday, 22 February 2007

Pattern of a Struggling Cricketer

What are Patterns?

Patterns are solutions for reoccurring problems that are seen over and over again in our environment and its surroundings. It also describes us about the solutions that’s should be adapted to the aroused problems and the main beneficial thing is that these solutions can be used over and over again for many similar problems. In simple words patterns are said to be reusable.
Patterns are also known as communications patterns because they can interact and communicate between different objects
Patterns can exist at many levels of an object from a basic level to generalized and complicated level areas.

Benefits gained from Patterns

Its is reusable can be used again to different similar problems
Takes less no of time to solve a problem
Provides many solutions to a particular problem

Patterns in real time situation

Problem – Cricket is an unpredictable game! How can batsmen who are currently facing a problem of getting dismissed in a similar delivery overcome from this problem?
Context – A batsmen has got out in a similar delivery outside the off stump always when ever he tries to play a shot to that particular delivery he hits ball in the air and he gets out. This has happened to him in many occasions in all these occasions he has misjudged the length of the delivery. His has let his team down in many occasions when they wanted him to score for them
His opposition team has found his weak point and they always ball the similar short delivery to him to attempt him to go for a short which he always does to score from it and he gets out

Solutions – To overcome this problem the player can be much more patient and avoid similar deliveries in the off stump with outplaying it or scoring from it. He can avoid the particular delivery at all and make the opposition team discourage of bowling itto him and they might bowl another delivery in which he can score from



Example – score enough runs from other deliveries bowled.
Related Patterns – can take a training session of how to face a similar delivery when he is out of the game. Can use the simmilar solutions to orther problem or weak points faced in batting