1

Software Construction

CNG 353

Lecture 1

Introduction
Course Goal & Objectives
Goal: To enable students to adopt OO and
software design patterns in their software
designs (advanced design).

Objectives:
Discuss Basic Design Patterns.
Discuss Creational Design Patterns.
Discuss Collectional Design Patterns.
Discuss Structural Design Patterns.
Discuss Behavioral Design Patterns.
Discuss Concurrency Patterns.


2
Prerequisites
CNG 213 (Unofficial)- DS
CNG 351 (Unofficial)- DB
CNG 443 (Unofficial)- OO

3
Text Book
4
Partha Kuchana is an
enterprise systems
architect.
Steven J ohn Metsker is a
researcher
Learning Outcomes
Ability to differentiate between different
OO design patterns and recognize the
contexts of their usage.

Ability to provide high quality reusable OO
system designs using different OO design
patterns.

5
Grading
Course Project: 40% Design
20% Implementation
Assignments: 10%
MD1: 10 %
Final: 20 %

6
What is a pattern?
Each pattern describes a problem which
occurs over and over again in our
environment, and then describes the core
of the solution to that problem, in such a
way that you can use this solution a million
times over, without ever doing it the same
way twice.

Charles Alexander

7
Pattern Quotes
A pattern is an idea that has been useful in one
practical context and will probably be useful in
others
Martin Fowler
A pattern is a three-part rule, which expresses a
relation between a certain context, a problem,
and a solution
Christopher Alexander
History
Christopher Alexander
A Pattern Language: Towns, Buildings, Construction (1977)
A Timeless Way of Building (1979)

Gang of Four (Erich Gamma, Richard
Helm, Ralph Johnson, John Vlissides)
Design Patterns (1995)

Buschmann et al
Pattern Oriented Software Construction (1996)
Key Idea
A Software Pattern is:
A solution
To a problem
In a context
With consequences
A Software Pattern has a name and a
vocabulary.
Elements of Design Patterns
Pattern Name
Increases design vocabulary, higher level of abstraction
Problem
When to apply the pattern
Problem and context, conditions for applicability of pattern
Solution
Relationships, responsibilities, and collaborations of design
elements
Not any concrete design or implementation, rather a template
Consequences
Results and trade-offs of applying the pattern
Space and time trade-offs, reusability, extensibility, portability
Benefits
Leverage a Proven Solution.
Improves thinking about OO design
New designs
Existing designs
Helps us realise the benefits of OO
Reuse of solutions to common problems
Cataloges
Communication tool
Common vocabulary
Leverage a Proven Solution
The solution for a pattern has been designed,
implemented and tested
Reusing these solutions allows most of each of these
steps to be eliminated
If the implementation of a pattern is used, the design,
implementation, and testing are minimal just to
ensure the proper behaviour exists
If the design of a pattern is used, the solution specific
to the problem must be implemented and tested, but
need not be redesigned
Provide a Common Vocabulary
Some patterns are very common
Documenting and cataloguing patterns allows
designers and architects to describe a solution using
patterns as part of the language
Typically, this can make descriptions of solutions shorter
Architects and designers can more easily
communicate their designs to their developers
Design Patterns are NOT
Data structures that can be encoded in classes and
reused as is (i.e., linked lists, hash tables)
Complex domain-specific designs
(for an entire application or subsystem)
If they are not familiar data structures or complex
domain-specific subsystems, what are they?

They are:
Descriptions of communicating objects and classes
that are customized to solve a general design problem
in a particular context.
Design patterns you have already
seen


Encapsulation (Data Hiding)
Subclassing (Inheritance)
Iteration
Exceptions

Encapsulation pattern
Problem: Exposed fields are directly
manipulated from outside, leading to
undesirable dependences that prevent
changing the implementation.

Solution: Hide some components,
permitting only stylized access to the
object.
Exception pattern
Problem: Code is cluttered with error-
handling code.

Solution: Errors occurring in one part of
the code should often be handled
elsewhere. Use language structures for
throwing and catching exceptions.
Types of design patterns
Design patterns can be (roughly) grouped into three
categories:

Creational patterns
Constructing objects

Structural patterns
Controlling the structure of a class, e.g. affecting the
API or the data structure layout

Behavioral patterns
Deal with how the object behaves (duh!)
Specialised Fields Patterns
Real-time
Concurrency
Enterprise
Messaging
Analysis
Refactoring to Patterns
Remove duplicate code
Simplify logic
Communicate intention
Increase flexibility
Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter (class) Interpreter
Template Method
Object Abstract Factory
Builder
Prototype
Singleton
Adapter (object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of
Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Defer object creation to
another class
Defer object creation to
another object
Describe algorithms and
flow control
Describe ways to
assemble objects
Design Pattern Space
25
How Design Patterns Solve Design
Problems
Finding Appropriate Objects
Determining Object Granularity
Specifying Object Interfaces
Specifying Object Implementations
Putting Reuse Mechanisms to Work
Relating Run-Time and Compile-Time
Structures
Designing for Change
How Design Patterns Solve
Design Problems
Finding Appropriate Objects
Decomposing a system into objects is the hard part
OO-designs often end up with classes with no counterparts in
real world (low-level classes like arrays)
Strict modeling of the real world leads to a system that reflects
todays realities but not necessarily tomorrows
Design patterns identify less-obvious abstractions

Determining Object Granularity
Objects can vary tremendously in size and number
Facade pattern describes how to represent subsystems as
objects
Flyweight pattern describes how to support huge numbers of
objects
Specifying Object Interfaces
Interface:
Set of all signatures defined by an objects operations
Any request matching a signature in the objects interface may be
sent to the object
Interfaces may contain other interfaces as subsets
Type:
Denotes a particular interfaces
An object may have many types
Widely different object may share a type
Objects of the same type need only share parts of their
interfaces
A subtype contains the interface of its supertype
Dynamic binding, polymorphism
Program to an interface,
not an implementation
- Manipulate objects solely in terms of interfaces
defined by abstract classes!

Benefits:
1. Clients remain unaware of the specific types of objects they use.
2. Clients remain unaware of the classes that implement the
objects.
Clients only know about abstract class(es) defining the interface

- Do not declare variables to be instances of particular concrete
classes
- Use creational patterns to create actual objects.
Favor object composition
over class inheritance
White-box reuse:
Reuse by subclassing (class inheritance)
Internals of parent classes are often visible to
subclasses
works statically, compile-time approach
Inheritance breaks encapsulation
Black-box reuse:
Reuse by object composition
Requires objects to have well-defined interfaces
No internal details of objects are visible
Designing for Change
Causes for Redesign (I)
Creating an object by specifying a class explicitly
Commits to a particular implementation instead of an
interface
Can complicate future changes
Create objects indirectly
Patterns: Abstract Factory, Factory Method, Prototype
Dependence on specific operations
Commits to one way of satisfying a request
Compile-time and runtime modifications to request
handling can be simplified by avoiding hard-coded
requests
Patterns: Chain of Responsibility, Command
Causes for Redesign (II)
Dependence on hardware and software platform
External OS-APIs vary
Design system to limit platform dependencies
Patterns: Abstract Factory, Bridge
Dependence on object representations or
implementations
Clients that know how an object is represented,
stored, located, or implemented might need to be
changed when object changes
Hide information from clients to avoid cascading
changes
Patterns: Abstract factory, Bridge, Memento, Proxy
Causes for Redesign (III)
Algorithmic dependencies
Algorithms are often extended, optimized, and
replaced during development and reuses
Algorithms that are likely to change should be isolated
Patterns: Builder, Iterator, Strategy, Template
Method, Visitor
Tight coupling
Leads to monolithic systems
Tightly coupled classes are hard to reuse in isolation
Patterns: Abstract Factory, Bridge, Chain of
Responsibility, Command, Facade, Mediator,
Observer
Causes for Redesign (IV)
Extending functionality by subclassing
Requires in-depth understanding of the parent class
Overriding one operation might require overriding
another
Can lead to an explosion of classes (for simple
extensions)
Patterns: Bridge, Chain of Responsibility, Composite,
Decorator, Observer, Strategy
Inability to alter classes conveniently
Sources not available
Change might require modifying lots of existing
classes
Patterns: Adapter, Decorator, Visitor
List of GoF Design Patterns
Creational Patterns
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Structural Patterns
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
Antipatterns
An antipattern is a pattern that may be
commonly used but is ineffective and/or
counterproductive in practice.

Examples
Big Ball Of Mud
Copy and Paste Programming
Magic Container
Tower of Voodoo
Project management anti-patterns
Avalanche: An inappropriate mashup of the Waterfall model and Agile Development
techniques
Death march: Everyone knows that the project is going to be a disaster except the
CEO so the truth is hidden to prevent immediate cancellation of the project -
(although the CEO often knows and does it anyway to maximize profit). However, the
truth remains hidden and the project is artificially kept alive until the Day Zero finally
comes ("Big Bang"). Alternative definition: Employees are pressured to work late
nights and weekends on a project with an unreasonable deadline.
Groupthink: During groupthink, members of the group avoid promoting viewpoints
outside the comfort zone of consensus thinking
Overengineering: Spending resources making a project more robust and complex
than is needed
Smoke and mirrors: Demonstrating unimplemented functions as if they were already
implemented
Software bloat: Allowing successive versions of a system to demand ever more
resources
Waterfall model: An older method of software development that inadequately deals
with unanticipated change

37
Software design anti-patterns
Abstraction inversion: Not exposing implemented functionality required by users, so
that they re-implement it using higher level functions
Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and
design (OOAD)) without specifying its viewpoint
Big ball of mud: A system with no recognizable structure
Database-as-IPC: Using a database as the message queue for routine interprocess
communication where a much more lightweight mechanism would be suitable
Gold plating: Continuing to work on a task or project well past the point at which extra
effort is adding value
Inner-platform effect: A system so customizable as to become a poor replica of the
software development platform
Input kludge: Failing to specify and implement the handling of possibly invalid input
Interface bloat: Making an interface so powerful that it is extremely difficult to
implement
Magic pushbutton: Coding implementation logic directly within interface code, without
using abstraction
Race hazard: Failing to see the consequence of different orders of events
Stovepipe system: A barely maintainable assemblage of ill-related components
38
Object-oriented design anti-patterns
Anemic Domain Model: The use of domain model without any business logic. The
domain model's objects cannot guarantee their correctness at any moment, because
their validation and mutation logic is placed somewhere outside (most likely in
multiple places).
BaseBean: Inheriting functionality from a utility class rather than delegating to it
Call super: Requiring subclasses to call a superclass's overridden method
Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
Circular dependency: Introducing unnecessary direct or indirect mutual dependencies
between objects or software modules
Constant interface: Using interfaces to define constants
God object: Concentrating too many functions in a single part of the design (class)
Object cesspool: Reusing objects whose state does not conform to the (possibly
implicit) contract for re-use
Object orgy: Failing to properly encapsulate objects permitting unrestricted access to
their internals
Poltergeists: Objects whose sole purpose is to pass information to another object
Sequential coupling: A class that requires its methods to be called in a particular
order
Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to
excessive fragmentation

39
Deprecated Patterns

Factory Method
Bridge
Flyweight
Interpreter

Your project
User and system requirements
Use Cases
System Architecture Diagrams
Class Diagrams
41