Lecture 9: Patterns and antipatterns 1

1
Lecture 9 Patterns (and anti-patterns) (1)

• In the book Design Patterns (ISBN 0201633612)
  Gamma et al, proposed standardised solutions
  and naming conventions for common problems in
  software design
• n.b. the patterns are those due to class-based OO
  programming languages and, more specifically,
  those patterns identified in (and hence
  represented in!) C programs and larger-scale
  software systems
• Why this n.b.? Well, maybe design patterns can
  be found for software written in other languages
  of other paradigms, maybe patterns from other
  languages of other paradigms are problematic when
  implemented in newer paradigms
• Also, more generally, there may be design
  patterns in other forms of language,
  notation-technique, and even modern approaches to
  software development
• In an Architectural context, design patterns were
  originally intended (amongst other things) to
  provide a common vocabulary and framework for all
  those involved in the design of a building (or
  community) including Architects, Customers,
  Building Engineers, etc.

2
(2)

• Class-based OO design patterns are often
  classified (n.b. there are several competing
  classifications)
• It is evident that
• A) Creational Design Patterns are the least in
  number
• B) Structural Design Patterns are the next larger
  in number
• C) Behavioural Design Patterns are so numerous it
  may now be impossible to enumerate them all!
• An example classification http//hillside.net/pat
  terns/books/Siemens
• Architectural Patterns
• An architectural pattern expresses a fundamental
  structural organization or schema for software
  systems. It provides a set of predefined
  subsystems, specifies their responsibilities, and
  includes rules and guidelines for organizing the
  relationships between them.
• Design Patterns
• A design pattern provides a scheme for refining
  the subsystems or components of a software
  system, or the relationships between them. It
  describes commonly recurring structure of
  communicating components that solves a general
  design problem within a particular context.
• Idioms
• An idiom is a low-level pattern specific to a
  programming language. An idiom describes how to
  implement particular aspects of components or the
  relationships between them using the features of
  the given language.

3
(3)

• The essential elements of a pattern which should
  be evident from its definition are-
  http//www.cmcrossroads.com/bradapp/docs/patterns-
  intro.html
• Name
• It must have a meaningful name. This allows us to
  use a single word or short phrase to refer to the
  pattern, and the knowledge and structure it
  describes. It would be very unwieldy to have to
  describe or even summarize the pattern every time
  we used it in a discussion. Good pattern names
  form a vocabulary for discussing conceptual
  abstractions. Sometimes a pattern may have more
  than one commonly used or recognizable name in
  the literature. In this case it is common
  practice to document these nicknames or synonyms
  under the heading of Aliases or Also Known As.
  Some pattern forms also provide a classification
  of the pattern in addition to its name.
• Problem
• A statement of the problem which describes its
  intent the goals and objectives it wants to
  reach within the given context and forces. Often
  the forces oppose these objectives as well as
  each other (one might think of this as a "wicked
  problem" reminiscent of DeGrace and Stahl, in
  their book Wicked Problems, Righteous Solutions).
  
• Context
• The preconditions under which the problem and its
  solution seem to recur, and for which the
  solution is desirable. This tells us the
  pattern's applicability. It can be thought of as
  the initial configuration of the system before
  the pattern is applied to it.

4
(4)

• Forces
• A description of the relevant forces and
  constraints and how they interact/conflict with
  one another and with goals we wish to achieve
  (perhaps with some indication of their
  priorities). A concrete scenario which serves as
  the motivation for the pattern is frequently
  employed (see also Examples). Forces reveal the
  intricacies of a problem and define the kinds of
  trade-offs that must be considered in the
  presence of the tension or dissonance they
  create. A good pattern description should fully
  encapsulate all the forces which have an impact
  upon it. A list of prospective pattern forces for
  software may be found in the answer to question
  11 of Doug Lea's Patterns-Discussion FAQ.
• Solution
• Static relationships and dynamic rules describing
  how to realize the desired outcome. This is often
  equivalent to giving instructions which describe
  how to construct the necessary work products. The
  description may encompass pictures, diagrams and
  prose which identify the pattern's structure, its
  participants, and their collaborations, to show
  how the problem is solved. The solution should
  describe not only static structure but also
  dynamic behavior. The static structure tells us
  the form and organization of the pattern, but
  often it is the behavioral dynamics that make the
  pattern "come alive". The description of the
  pattern's solution may indicate guidelines to
  keep in mind (as well as pitfalls to avoid) when
  attempting a concrete implementation of the
  solution. Sometimes possible variants or
  specializations of the solution are also
  described.
• Examples
• One or more sample applications of the pattern
  which illustrate a specific initial context how
  the pattern is applied to, and transforms, that
  context and the resulting context left in its
  wake. Examples help the reader understand the
  pattern's use and applicability. Visual examples
  and analogies can often be especially
  illuminating. An example may be supplemented by a
  sample implementation to show one way the
  solution might be realized. Easy-to-comprehend
  examples from known systems are usually preferred
  (see also Known Uses).

5
(5) Other Considerations

• More generally, (i.e. than by classification,
  their required structure, etc) design patterns
  have quasi-philosophical properties!
• Metaphor and Metonymy in Object-Oriented Design
  Patterns, Noble, et al.
• http//delivery.acm.org/10.1145/570000/563823/p1
  87- noble.pdf?key1563823key21363608511colldl
  A CMCFID15151515CFTOKEN6184618
• The key principle of object-oriented design is
  that each program object should correspond to an
  object in the real world,
• that is to say, a program is a metaphor for the
  world.
• More advanced object-oriented designs, such as
  many of Gamma et. al.'s Design Patterns, are not
  directly metaphorical State objects, Strategy
  objects and Visitor objects, for example, do not
  correspond to objects in the real world.
• Such.. patterns, and other similar designs,
  can be understood
• as metonymy, rather than metaphor, that is,
  they are based on
• an attribute, cause, or effect, rather than
  being based on something in the world
• Example metaphor
• Calling King Richard the "lion-heart" (he is a
  king, not a lion)
• Example metonymy
• Calling King Richard the "crown" (wearing a crown
  is one attribute of being a king)

6
(6) Other considerations (continued)

• In this argument, the majority of the design
  patterns are metonymy rather than metaphor.
• The Abstract Factory, Builder, and Factory Method
  patterns, for example, are about causing other
  objects to be created
• The Command, Decorator, Strategy, Mediator,
  Memento, and Visitor patterns model requests,
  responsibilities, algorithms, interactions,
  snapshots of internal states, and traversal
  operations, respectively
• Some (OO) design patterns that are neither
  metaphor or metonymy.
• Facade pattern, inserts an extra interface into a
  program to encapsulate a set of objects forming a
  subsystem.
• This extra interface is typically nothing to do
  with any external reality, it is purely about the
  internal structure of the software.
• Flyweight is another pattern in this category.
• Such patterns are arguably "programmatic" because
  they are about the internal structure of programs
  rather than their relation to an external
  reality.
• Many original GoF Patterns are programmatic
  patterns, including the Layers, Blackboard, Pipes
  and Filters, and Counted Pointer patterns.

7
Anti-patterns (7)

• Typically, (class-based OO) design patterns are
  reasoned about in terms of a tight interaction
  of a small number of classes and objects.
• (n.b. by implication, algorithms and
  procedural reasoning is NOT concerned with
  design patterns, but see later programmatic
  patterns)
• Anti-patterns are programming problems that
  should be avoided pitfalls for the unwary
• Singleton pattern is aprox. the simplest design
  pattern.
• Restricts instantiation of a class to one
  objects, c.f. a single global variable with
  state
• Implemented via a class with a method that
  creates a new instance of the object if no single
  instance currently exists, else returns a
  reference to the object that currently exists.
• The constructor is made either private or
  protected.
• BUT, must be carefully constructed in
  multi-threaded applications, usual solution is
  mutual exclusion on class that indicates that the
  object is being instantiated.

8
Anti-Patterns (continued) (8)

• Example Java solution for multi-threaded-
• public class Singleton
• private static Singleton INSTANCE null //
  Private constructor suppresses default
  public constructor
• private Singleton() //synchronized creator
  to defend against multi-threading issues
  another if check to avoid
• multiple instantiation
• private synchronized static void
  createInstance()
• if (INSTANCE null) INSTANCE new
  Singleton()
• public static Singleton getInstance()
• if (INSTANCE null) createInstance()
  return INSTANCE

9
(9)

• Some consider the singleton pattern to be a
  classic example of an anti-pattern
• It can be used to model global variables with
  (shared) state
• Thus, pattern vs anti-pattern is an ongoing
  debate
• Patterns proved less than useful in their
  original domain (i.e. architecture)
• Have now been used for everything from software
  design patterns to pedagogical patterns (or
  teaching/educational patterns)
• Some have sought to formalise (c.f. Formal
  Methods) patterns
• http//www.edenstudy.org/precise_and_formal/bibli
  ography.htmformal
• There are even pattern-enforcing compilers
  https//pec.dev.java.net/

10
Beyond Class-based OO design Patterns (10)

• It is evident that OO design patterns are bound
  to the class-based OO programming language
  paradigm
• e.g. Singleton Pattern is due to class construct
  imposing no constraint on the number of instances
  of a class
• There are arguably design patterns (i.e.
  non-class based OO design patterns) known for
  other paradigms
• e.g. Program Design by Recursive Descent (PDRD)
  is a design pattern for the imperative-procedura
  l language paradigm
• http//portal.acm.org/citation.cfm?id345113coll
  ACMdlACMCFID14736454CFTOKEN19410706
  provides a SmallTalk based realisation using the
  Interpreter, Strategy and Visitor patterns
• http//portal.acm.org/citation.cfm?id1047497coll
  ACMdlACMCFID14736454CFTOKEN19410706
• explains again how the Visitor Pattern can be
  used to realise a predictive recursive descent
  parser
• http//portal.acm.org/citation.cfm?doid960492.960
  534 provides an example of how such a parser can
  be realised in C
• The significance of these examples is that-
• Objects (via classes) were unnecessary for the
  satisfactory realisation of a parser in an
  imperative-procedural language
• Objects (via classes) must be accommodated in a
  class-based OO programming language
  implementation
• The original design pattern (PDRD) was known long
  before it was translated into its class-based
  OO equivalent

11
Symmetry and its breaking (11)

• One way of characterising a class-based OO design
  pattern is that it breaks so-called symmetries
  due to the class-based OO programming language
  paradigm
• http//www.jot.fm/issues/issue_2003_09/article3
• However, it is possible to argue that, e.g. a
  class construct, simply imposes the constraint
  that all objects can only be created and
  subsequently manipulated via their class, and
  hence
• That a design pattern does not break any
  symmetry due to the concept of a class
• It simply provides a means of (re)organising
  classes that is known to achieve some
  computational effect via a class structure that
  is arguably more optimal (but in any case
  different than the original organisation) in some
  way

12
Deeper unbreakable Symmetries (12)

• Arguably deeper symmetries may also be present,
  e.g. the symmetry due to the typing rules of a
  given language, a symmetry that simply cannot be
  broken by legal programs written in a given
  language
• Thus, (re)organising classes (a.k.a. refactoring)
  such that they exhibit the structure due to a
  design pattern still requires that the program
  containing those (re)organised classes is a legal
  program in a given language according to the
  typing rules of the given language
• Other examples of non-class-based symmetries
  and design patterns include-
• The symmetry that is a triple in a program
  written for a Turing Machine
• (new state, new symbol, new cell)
• The symmetry a TAC instruction
• The modular imperative-procedural design
  pattern- encapsulate an object of a hidden
  type (see earlier lecture)
• Etc, etc
• Is there something more general to design
  patterns than any meaning due to the original
  book by Gamma?
• Well, first and foremost, design patterns were
  originally an Architectural (of all disciplines!)
  notion

13
On the Limits of Symmetry as an Analogy (13)

• If, as has been argued here, design patterns can
  be generalised in the sense that they can be seen
  to be bound to a given language paradigm, then
  maybe a further incremental generalisation to
  other forms of description produced, and even
  activity undertaken, during software development
  is possible
• In so-called Agile approaches to software
  development it is often argued that The software
  should be in a working state at all times
• Setting aside how we measure what a working
  state is, this maxim does impose a kind of
  symmetry on developers, indeed, the symmetry is
  that very requirement, i.e. the software will be
  in a working state
• How we ensure this property of the software is
  problematic, but we may, for example, program to
  interfaces as a technique to help ensure
  (together with other characteristics that
  programming to an interface ensures) that the
  software is always in a working state
• It is possible to over-emphasise symmetry, and we
  must be careful not to find so-called symmetries
  everywhere!

14
Disappearing Patterns (14)

• It has become evident that some languages (of
  other language paradigms, but sometimes embodying
  the object oriented paradigm) do not require
  users to exploit design patterns
• Such languages embody the design pattern as a
  language construct directly
• Example The factory pattern is fundamental in
  Python (a language of the functional language
  paradigm)
• Where other languages use special syntax to
  indicate creation of an object, Python uses
  function call syntax as the (almost) only way to
  create any object
• Indeed, Python uses abstract factories for
  everything. The dynamic nature of the language
  means that any factory may be overridden
• Python and Singleton Pattern
• Singleton Pattern led Python programmers to
  invent one of the few genuine Python Patterns
  with a name The Borg.
• The Borg pattern allows multiple class instances,
  but shares state between instances so the
  end-user cannot tell them apart.

15
Summary and Conclusions (15)

• The need to communicate quite specific concepts
  led to the development of a language of design
  patterns
• Initially, all such design patterns were due to
  class-based OO languages (more specifically C)
• More generally, there are design patterns, both
  discovered and to be discovered, that are bound
  to each language paradim
• When examined more closely, e.g. as categories of
  pattern, (OO) design patterns were recognised as
  overwhelmingly metonymy rather than metaphor
• (OO) Design Patterns are often based on an
  attribute, cause, or effect, rather than being
  based on something in the world
• Any symmetries that are broken by design
  patterns are only (weak) symmetries, e.g. those
  symmetries due to particular (chosen)
  organisations of classes in a class hierarchy
• Some languages (of other language paradigms, but
  sometimes embodying the object oriented paradigm)
  do not require users to exploit design patterns
• Such languages embody the design pattern
  directly, e,g. as a language construct