SOFTWARE ARCHITECTURE AND
DESIGN PATTERNS
BMS Institute of Technology and Mgmt
Module-3
Design Pattern Catalog
Structural Patterns
Design Patterns are of 3 types:
1. Creational : address problems of creating an object in a
flexible way, separate creation from operation/use.
2. Structural : address problems of using O-O constructs like
inheritance to organize classes and objects.
3. Behavioral: address problems of assigning responsibilities
to classes. Suggest both static relationships and patterns of
communication (use case)
Structural Patterns
Structural patterns are concerned with how classes and objects are
composed to form larger structures.
Structural class patterns use inheritance to compose interfaces
or implementations.
This pattern is particularly useful for making independently
developed class libraries work together.
Structural object patterns describe ways to compose objects to
realize new functionality.
The added flexibility of object composition comes from the
ability to change the composition at runtime, which is
impossible with static class composition.
A common ways to describe a design pattern is the
use of the following template:
1. Pattern Name and Classification
2. Intent
3. Also Known As
4. Motivation (Problem, Context)
5. Applicability (Solution)
6. Structure (a detailed specification of structural aspects)
7. Participants, Collaborations (Dynamics)
8. Implementation
9. Example
10. Known Uses
11. Consequences
12. Related patterns
Adapter (Non software example)
Convert the
interface of a
class into another
Interface clients
expect.
Department
Departmentof
of ISE
ISE BMS Institute of Tec
Pattern Name: Adapter
Intent:
Convert the interface of a class into another interface clients
expect. Adapter lets classes work together that could not
otherwise because of incompatible interfaces.
Collaborations:
Clients call operations on an Adapter instance. In turn, the
adapter calls Adaptee operations that carry out the request.
Also Known As: Wrapper
Adapter…
Motivation:
Sometimes a toolkit class that's designed for reuse isn't
reusable only because its interface doesn't match the domain-
specific interface an application requires.
Consider for example a drawing editor that lets users draw and
arrange graphical elements (lines, polygons, text, etc.) into
pictures and diagrams.
The interface for graphical objects is defined by an abstract
class called Shape.
The editor defines a subclass of Shape for each kind of
graphical object.
Classes for elementary geometric shapes are easy to
implement. But a TextShape subclass that can display and edit
text is more difficult to implement. (screen updates, buffer
updates)
How can existing and unrelated classes like TextView
work in an application that expects classes with a different
and incompatible interface?
• We could define TextShape so that it adapts the TextView
interface to Shape's.
1. by inheriting Shape's interface and TextView's
implementation or
2. by composing a TextView instance within a TextShape and
implementing TextShape in terms of TextView's interface.