Software Architecture and

Design Pattern
Idioms : Introduction
Idioms are low-level patterns specific to a programming language.
An idiom describes how to implement particular aspects of
components or the relationships between them with the features of
the given language.
Idioms : Introduction
Idioms describe how to solve implementation-specific problems in a
programming language, such as memory management in C++
We cannot therefore draw a clear line between design patterns and
idioms
Idioms can address low-level problems related to the use of a
language, such as naming program elements, source text formatting
or choosing return values
Idioms : Introduction
A programming style is characterized by the way language constructs
are used to implement a solution, such as the kind of loop statements
used, the naming of program elements, and even the formatting of
the source code
Each of these separate aspects can be cast into an idiom, whenever
implementation decisions lead to a specific programming style.
A collection of such related idioms defines a programming style
What Can Idioms Provide?
A single idiom might help you to solve a recurring problem with the
programming language you normally use.
Examples of such problems are memory management, object creation,
naming of methods, source code formatting for readability, efficient use of
specific library components and so on
There are several ways to acquire expertise in solving such problems
One is by reading programs developed by experienced programmers, This
approach takes a long time
If a set of idioms are available for you to learn, it is much easier to become
productive in a new programming language, because the idioms can teach
you how to use the features of a programming language effectively to solve
a particular problem
What Can Idioms Provide?
Idioms are less 'portable' between programming languages
For example, the design of Smalltalk's collection classes incorporates
many idioms that are specific to the language.
They depend on features not present in C++ such as garbage collection
or meta-information
Idioms and Style
A good program written by a single programmer will contain many
applications of his set of patterns.
Knowing the patterns a programmer uses makes understanding their
programs a lot easier.
It may be difficult to follow a consistent style, however, even for an
experienced programmer.
If programmers who use different styles form a team, they should
agree on a single coding style for their pro- grams
Idioms and Style
A good program written by a single programmer will contain many
applications of his set of patterns.
Knowing the patterns a programmer uses makes understanding their
programs a lot easier.
It may be difficult to follow a consistent style, however, even for an
experienced programmer.
If programmers who use different styles form a team, they should
agree on a single coding style for their programs
Idioms and Style
String copy function

The function strcopyKR ( ) uses pointers as synonyms for array parameters, in the terse C style in the tradition
of Kernighan and Ritchie
Idioms and Style
 Both implementations follow their own style.
 Which version you prefer, or what your own version would look like, depends on
your experience, background, taste and many other factors
 A program that uses a mixture of both styles might be much harder to understand
and maintain than a program that uses one style consistently
Idioms and Style
Example of a style guide idiom from Kent Beck's Smalltalk Best Practice
Patterns
Name : Indented Control Flow
Problem : How do you indent messages?
Solution :
Idioms and Style
Solution :
Different sets of idioms may be appropriate for different domains
you can write C++ programs in an object-oriented style with
inheritance and dynamic binding
a more 'efficient' style that does not use dynamic binding is required
A single style guide can therefore be unsuitable for large companies
that employ many teams to develop applications in different domains
Where Can You Find Idioms?
For example, the Singleton design pattern [GHJV95] provides two
idioms specific to Smalltalk and C++
Name : Singleton (C++)
Problem : You want to implement the Singleton design pattern in C++,
to ensure that exactly one instance of a class exists at run-time
Solution : Make the constructor of the class private. Declare a static
member variable the Instance that refers to the single existing instance
of the class. Initialize this pointer to zero in the class implementation
file
Where Can You Find Idioms?
Define a public static member function qetInstance ( )
that returns the value of theInstance. The first time
qetInstance ( ) is called, it will create the single instance
with new and assign its address to theInstance

The corresponding Smalltalk version of Singleton solves

the same problem, but the solution is different because
Smalltalk's language concepts are completely distinct
from C++:
Idioms and Style
Name : Singleton (Smalltalk)
Problem : You want to implement the Singleton design pattern in
Smalltalk, to ensure that exactly one instance of a class exists at run-
time
Solution : Override the class method new to raise an error. Add a class
variable TheInstance that holds the single instance. Implement a class
method getInstance that returns TheInstance. The first time
qetInstance is called, it will create the single instance with super new
and assign it to TheInstance.
Idioms and Style
Solution :

 You can find a good collection of Smalltalk programming wisdom in the idioms presented in Kent Beck's
columns in the Smalltalk Report
 You can also look at your own program code, or the code of your colleagues, read it and extract the patterns
that have been used.
 You can use such 'pattern mining' to build a style guide for your programming language that becomes an
intellectual asset of your team.
Counted Pointer
The Counted Pointer idiom makes memory management of
dynamically-allocated shared objects in C++ easier.
It introduces a reference counter to a body class that is updated by
handle objects.
Clients access body class objects only through handles via the
overloaded operator-> ( ) .
Counted Pointer
Example:
When using C++ for object-oriented
development, memory management is an
important issue.
Whenever an object is shared by clients. each
of which holds a reference to it, two situations
exist that are likely to cause problems: a client
may delete the object while another client still
holds a reference to it, or all clients may
'forget' their references without the object
being deleted.
Counted Pointer
Context: Memory management of dynamically allocated instances of a
class
Problem :
In every object-oriented C++ program you have to pass objects as
parameters of functions.
It is typical to use pointers or references to objects as parameters.
This allows you to exploit polymorphism. However, passing object
references around freely can lead to the situations shown in the
diagram above-you do not know if references are still valid, or even still
needed.
Counted Pointer
Problem :
One approach to the problems arising from the use of pointers and
references is to avoid them completely and pass objects by value, as is
normally done with integers.
C++ allows you to create programs that do this, and the compiler will
automatically destroy value objects that go out of scope.
Counted Pointer
This solution does not work well for all kinds of program, however, for
three reasons.
1. Firstly, if the objects you pass by value are large, copying them each
time they are used is expensive in run-time and memory
consumption.
2. Secondly, you might want to create dynamic structures of objects,
such as trees or directed graphs, which is almost impossible to do in
C++ using value objects alone.
3. Lastly, you may want to share an object deliberately, for example by
storing it in several collections.
Counted Pointer
If you have to deal with references or pointers to dynamically allocated
objects of a class, you may need to address the following forces:
Passing objects by value is inappropriate for a class.
Several clients may need to share the same object.
You want to avoid 'dangling' references-references that has been deleted.
If to an object a shared object is no longer needed, it should be destroyed
to conserve memory and release other resources it has acquired.
Your solution should not require too much additional code within each
client.
Counted Pointer
The solution involves making only a small addition to the object being
shared and adding another class
Two classes are involved in the solution:
• Body: The body is the object that will be referenced and shared; it
probably exists already. A reference counter in the body keeps track
of the number of pointers to it by other objects.
• Handle: The handle is introduced as the only class in the system that's
allowed to have a reference directly to the body.
Counted Pointer
Solution:
The Counted Pointer idiom eases memory management of shared objects
by introducing reference counting.
The class of the shared objects, called Body, is extended with a reference
counter.
To keep track of references used, a second class Handle is the only class
allowed to hold references to Body objects.
All Handle objects are passed by value throughout the program, and
therefore are allocated and destroyed automatically.
The Handle class takes care of the Body object's reference counter.
By overloading operator - > ( ) in the Handle class, its objects can be used
syntactically as if they were pointers to Body objects.
Counted Pointer

snapshot of the system with several handles all pointing to the same body.
Counted Pointer
Implementation :
To implement the Counted Pointer idiom, carry out the following steps:
1. Make the constructors and destructor of the Body, class private (or protected) to prohibit its uncontrolled
instantiation and deletion.
2. Make the Handle class a friend to the Body class, and thus provide the Handle class with access to Body's
internals.
3. Extend the Body class with a reference counter.
4. Add a single data member to the Handle class that points to the Body object.
5. Implement the Handle class' copy constructor and its assignment operator by coping the Body object pointer
and incrementing the reference counter of the shared Body object. Implement the destructor of the Handle
class to decrement the reference counter and to delete the Body object when the counter reaches zero.
6. lmplement the arrow operator of the Handle class as follows: Body * operator->() const { return body; 1 and
make it a public member function.
7. Extend the Handle class with one or several constructors that create the initial Body instance to which it
refers. Each of these constructors initializes the reference counter to one.
Counted Pointer
Counted Pointer
Counted Pointer
Counted Pointer
Wrapping the body with a counter class
Counted Pointer
Koenig's variant with a Count class
Pattern Systems
 A pattern system ties individual patterns together.
 It describes how its constituent patterns are connected with other patterns in the system, how
these patterns can be implemented, and how software development with patterns is supported.
 A pattern system is a powerful vehicle for expressing and constructing software architectures
What is a Pattern System?
 Patterns do not exist in isolation-there are many interdependencies between them
 A pattern system ties its constituent patterns together. It describes how the patterns are connected and how
they complement each other.
 A pattern system also supports the effective use of patterns in software development
What is a Pattern System?
Christopher Alexander uses the term 'language' instead of 'system' to describe the same concept
 The elements [of a pattern language] are patterns. There is a structure on the patterns, which describes how
each pattern is itself a pattern of other smaller patterns.
 And there are also rules, embedded in the patterns, which describe the way that they can be created, and the
way that they must be arranged with respect to other patterns.
 However, in this case, the patterns are both elements and rules. so rules and elements are indistinguishable.
The patterns are elements.
 And each pattern is also a rule, which describes the possible arrangements of the elements-themselves again
or other patterns.
What is a Pattern System?
A pattern system for software architecture is a collection of patterns for software
architecture, together with guidelines for their implementation. combination and
practical use in software development

The main objective of a pattern system for software architecture is to support the
development of high-quality software systems
To achieve this objective, a pattern system must meet the following requirements
 It should comprise a sufficient base of patterns
 It should describe all its patterns uniformly
 It should expose the various relationships between patterns
 It should organize its constituent patterns.
 It should support the construction of software systems
 It should support its own evolution
Pattern Classification
A pattern classification schema that sup- ports the development of software systems
using patterns should have the following properties

 It should be simple and easy to learn

 It should consist of only a few classification criteria
 Each classification criterion should reflect natural properties of patterns
 It should provide a 'roadmap' that leads users to a set of potentially- applicable
patterns
 The schema should be open to the integration of new patterns
Pattern Classification : Pattern Categories
The most fundamental classification criteria in our classification schema are the
pattern categories
 Architectural patterns can be used at the beginning of coarse- grained design,
when specifying the fundamental structure of an application.
 Design patterns are applicable towards the end of coarse-grained design, when
refining and extending the fundamental architecture of a software system, for
example deciding on the basic communication mechanisms between subsystems
 Idioms are used in the implementation phase to transform a software architecture
into a program written in a specific language
Pattern Classification : Problem Categories
Our second classification criterion provides a problem-oriented view of a pattern
system. Every pattern addresses a specific problem that may arise in the
development of software systems
Problem categories correspond directly to concrete design situations. They are
therefore a useful pattern classification criterion for patterns
Pattern Classification : Problem Categories
 From Mud to Structure includes patterns that support a suitable decomposition of an overall
system task into cooperating subtasks.
 Distributed Systems includes patterns that provide infrastructures for systems that have
components located in different processes or in several subsystems and components.
 Interactive Systems includes patterns that help to structure systems with human-computer
interaction.
 Adaptable Systems includes patterns that provide infrastructures for the extension and adaptation
of applications in response to evolving and changing functional requirements.
 Structural Decomposition includes patterns that support a suitable decomposition of subsystems
and complex components into cooperating parts.
 Organization of Work includes patterns that define how components collaborate to provide a
complex service.
 Access Control includes patterns that guard and control access to services or components.
 Management includes patterns for handling homogenous collections of objects, services and
components in their entirety.
 Communication includes patterns that help to organize communication between components.
 Resource Handling includes patterns that help to manage shared components and objects.
Pattern Classification : The Classification Schema
 Both pattern categories and problem categories interweave to form a two-dimensional pattern
classification schema-for every pattern we can define its corresponding pattern and problem
categories
 The schema itself is very simple, expressive and easy to learn. There are only two classification
criteria.
 These correspond to two major aspects in software development: the general development
activity that must be performed, and the concrete problem that must be solved.
Pattern Classification : The Classification Schema
Pattern Classification : Comparison
Our classification schema is not the only one to be defined for organizing patterns
Like our schema, the Gang-of-Four's schema has two dimensions: purpose and scope.
The following paragraphs are an excerpt from the Gang-of-Four book

 The first criterion, called purpose. reflects what a pattern does. Patterns can have either creational,
structural, or behavioral purpose. Creational patterns concern the process of object creation.
Structural patterns deal with the composition of classes or objects. Behavioral patterns characterize
the ways in which classes or objects interact and distribute responsibility.
 The second criterion, called scope, specifies whether the pattern applies primarily to classes or to
objects. Class patterns deal with relationships between classes and their subclasses. These
relationships are established through inheritance, so they are static-fixed at compile-time. Object
patterns deal with object relationships, which can be changed at run-time and are more dynamic.
Pattern Selection
Procedure for selecting a specific pattern. It includes seven steps
1. Specify the problem: To be able to find a pattern that helps you solve a concrete problem, you
must first specify the problem precisely
2. Select the pattern category that corresponds to the design activity you are performing
3. Select the problem category that corresponds to the general nature of the design problem. Every
problem category broadly summarizes the types of problems addressed by the patterns it contains
4. Compare the problem descriptions. Each pattern in your selected problem category may address
a particular aspect of your concrete problem, and either a single pattern or a combination of
several can help to solve it
5. Compare benefits and liabilities. This step investigates the consequences of applying the patterns
selected so far
6. Select the variant that best implements the solution to your design problem
7. Select an alternative problem category. If there is no appropriate problem category, or if the
selected problem category does not include patterns you can use, try to select a problem category
that further generalizes your design problem
Pattern Systems as Implementation Guidelines
All our pattern descriptions provide steps and guidelines that specify their implementation.
They help with the task of transforming a given software architecture that does not include the
pattern into one that includes it.
The implementation steps can be seen as a micro-method for solving the specific problem addressed
by the pattern
Whenever another pattern is referenced, its implementation steps can be applied
Pattern Systems as Implementation Guidelines
Example: Implementing a Model-View-Controller architecture

The implementation section of Model-View-Controller refers to seven other patterns:

 Step 2: 'Implement the change-propagation mechanism' suggests the use of the Publisher-
Subscriber design pattern.
 Step 4: 'Design and implement the controllers' refers to the Command Processor design pattern.
 Step 5: 'Design and implement the view-controller relationship' refers to the Factory Method
design pattern.
 Step 7: 'Dynamic view creation' builds upon the View Handler design pattern.
 Step 9: 'Infrastructure for hierarchical views and controllers' uses the Composite IGHJV951 and
Chain of Responsibility patterns.
 Step 10: 'Further decoupling from system dependencies' suggests the application of the Bridge
pattern
Pattern Systems as Implementation Guidelines
Example: Implementing a Model-View-Controller architecture
Pattern Systems as Implementation Guidelines
Example: Implementing a Model-View-Controller architecture
The implementation steps for individual patterns are its building-blocks.
They can be plugged with the implementation steps of other patterns, namely those that refer to the
pattern you are implementing.
You can therefore solve complex problems by recursively applying the implementation steps of all
patterns that are involved in its solution

Patterns do not therefore define a new method for software development that replaces existing ones.
Instead, they complement general but problem-independent analysis and design methods with
guidelines for solving specific and concrete problems
Pattern Systems as Implementation Guidelines
Example: Implementing a Model-View-Controller architecture
We therefore suggest the following pragmatic approach to the development of software systems using
patterns
 Use any method you like to define an overall software development process and the detailed
activities to be performed in each development phase, such as Booch, Coad/Yourdon, Object
Modeling Technique, Shlaer/Mellor, Responsibility-Driven-Design or the Unified Method
 Use an appropriate pattern system to guide your design and implementation of solutions to specific
problems. Whenever this pattern system includes a pattern that addresses a design problem you
are faced with, use the implementation steps associated with that pattern to solve the problem
 If the pattern system does not include a pattern for your design problem, try to find a pattern from
other pattern sources you know
 If no pattern is available, apply the analysis and design guidelines of the method you are using.
These guidelines provide at least some useful support for solving the design problem at hand