Patterns

1
Patterns

• Roberto Damiani Mendes

2
Roteiro

• Definition
• Architecture Patterns
• Design Patterns
• GRASP Patterns

3
MOTIVATION

• Reuse
• Common Language

4
Definition

• Chirstopher Alexander says Each patterns
  describes a problem which occurs over and over
  again in our enviroment, and then describes their
  core of the solution to that problem, in such way
  that you can use this solution a million times
  over, without even doing it the same way twice.
• GOF

5
Definition

• Patterns help you build on collective
  experience of skilled software enginer. They
  capture existing, well-proven experience em
  software development and help to promote good
  design practise. Every patterns deals with a
  specific, recurring problem in the design or
  implementation of a sofware system. Patterns can
  be used to contruct software architectures with
  specific properties Buschmann.

6
Essential Elements

• A patterns has four essential elements
• Patterns name
• Problem
• Solution
• Consequences.

7
Pattern Name

• Its a handler we can use to describe a design
  problem, its soltutions, and consequences in a
  word or two.
• Finding good names has been one of the hardest
  parts of developing our catalog.
• GOF

8
Problem

• It describes when to apply the pattern. It
  explains the problem and its context.

9
Solution

• It describes the elements that make up the
  design, their relationships, responsibilities,
  and collaborations.

10
CONSEQUENCES

• The consequences are the results and trade-offs
  of applying the patterns.

11
ARCHITECTURAL PATTERNS

• Express fundamental structural organization
  schemas for software systems. They provide a set
  of predefined subsystems, specific their
  resposibilities, and include rules and guidelines
  for organizing the relationships between them
  Buschmann.
• Architectural patterns represent the
  highest-level patterns.

12
Pattern Layers (Problem)

• Source code changes are rippling throughout the
  system many part of systems are highly coupled
• Application logic is intertwined with user
  interface , and so can not be reused with a
  different interface, nor distributed to another
  processing node
• Potentially general technical services or
  business logic is intertnwined with more
  application-specfic logic, and so can not reused,
  distributed to another node, or easily replaced
  with different implementation
• There is high coupling across different areas
  concern. It is thus difficult to divide the work
  along clear bound aries for different developers
• Due to the high coupling and mixing of concerns,
  it is laborious and costly to evolve the
  applicattions functionality, scale up the
  system, or update it to use new technologies.

13
Pattern Layers (Solution)

• Organize the large-scale logical structure of a
  system into discrete layers of distinct, related
  responsibilities, with a clean, cohesive
  separation of concerns such that the lower
  layers are low-level and general services and
  higher layers are more applications specific
• Collaboration and coupling, is from higher to
  lower layers lower-to-higher layer coupling is
  avoided.

14
Pattern Layers
15
Inter-Layer and Inter Package Coupling
16
Inter-Layer and Inter Package Coupling
17
Inter-Layer and Inter-Package Interaction
Scenarios
18
DESIGN PATTERNS

• Design Patterns are medium-scale patterns. They
  are smaller in scale than architectural patterns,
  but are at a higher level than the programming
  language-specific idiom.

19
CLASSIFICATION

• Purpose should reflect what a pattern does.
• Creational -gtconcern the process of object
  creation.
• Structural -gtcategory deal with the composition
  of classes or objects
• Bahavioural -gtcharacterize the ways in which
  classes or objects interact and distribute
  responsibilities.

20
CLASSIFICATION

• Scope specify whether a pattern applies
  primarily to classes or to object.
• Object -gt deal with object relationships
• Class -gt deal with relationships between classes
  and their subclasses.

21
CLASSIFICATION

• GOF

22
ADAPTER

• Convert the interface of a class into another
  interface clients expect. Adapter lets classes
  work together that couldnt otherwise because of
  incompatible interfaces.

23
STRUCTURE
24
EXAMPLE
25
FACADE

• Provide a unified interface to a set of
  interfaces in a subsystem. Facade defines a
  higher-level interface that makes the subsystem
  easier to use

26
STRUCTURE
27
EXAMPLE
28
COMPOSITE

• Composite lets clients treat individual objects
  and compositions of objects uniformly

29
STRUCTURE
30
EXAMPLE
31
DESIGN OBJECT

• After identifying your requirements and creating
  a domain model, then add methods to the software
  classes, and define the messaging between the
  objects to fulfill the requeriments. Larman

32
DESIGN OBJECT

• Decide what method belong where, and how the
  objects should interact, is terribly important
  and anything but trivial.Larman

33
GRASPGeneral Responsibilitity Assignment
Software Patterns

• The GRASP Patterns are a learning aid to help one
  understand essencial object design, and apply
  design reasoning in a methodical, rational,
  explainable way.
• This approach to undestanding and using design
  principles is based on patterns of assigning
  responsibilities.

34
RESPONSIBILITY

• The UML define a responsibility as a contract
  or obligation of a classifier2
• They are assigned to classes of objects during
  object design
• The skilfull assignment of responsibilities is
  extremely important in object design
• Determining and assignment of responsibilities
  often occurs during the creation of interaction
  diagrams, and certainly during programming

35
RESPONSIBILITY x METHOD

• Responsibility is not same thing as a method, but
  method are implemented to fulfill
  responsibilities.

36
GRASP PATTERNS

• They describe fundamental principles of object
  design and responsibility assignments, expressed
  as patterns.
• GRASP Patterns
• Information Expert
• Creator
• High Cohesion
• Low Coupling
• Controller
• Polymorphism
• Fabrication
• Indirection
• Protected Variactions

37
INFORMATION EXPERT

• Problem What is a principle of assingment
  responsibilities to objects?
• Solution Assign a responsibility to the
  information expert. The class that has the
  information necessary to fulfill the
  resposibility.

38
CREATOR

• Problem Who should be responsible for creating a
  new instance os some class?
• SolutionAssign class B the resposibility to
  create an instance of class A if one or more of
  the following is true
• B aggregates A objects
• B cotains A objects
• B records instances of A objects
• B closely uses A object
• B has the initializing data that will be passed
  to A when it is created(thus B is an Expert with
  respect to creating A)

39
LOW COUPLING

• Problem How to support low dependency, low
  change impact, and increase reuse?
• Solution Assign a resposibility so that coupling
  reamains low.

40
HIGH COHESION

• ProblemHow to keep complexity manageable?
• Solution Assign a responsibility so that
  cohesion remains high

41
CONTROLLER

• Problem Who should be responsible for handling
  an input system event?

42
CONTROLLER

• SolutionAssign the responsibility for receiving
  or handling a system event message to a class
  representing one of the following choices
• Represents the overall system, device, or
  subsystem(facade controller)
• Represents a use case scenario within which the
  system event occurs.

43
POLYMORPHISM

• PROBLEM How to handle alternatives based on
  type? How create pluggable software components?
• Solution When related alternatives or behaviors
  vary by type(class), assign responsibility for
  the bahavior using polymorphic operations to
  the types for which the behavior varies.

44
FABRICATION

• Problem What object should have the
  responsibility when you do not want to violate
  High Cohesion and Low Coupling, or other goals,
  but solutions offered by Expert (for example) are
  not appropriate?
• SolutionAssign an highly cohesive set of
  responsibilities to an artificial or convenience
  class that does not represent a problem domain
  concept something made up, to support high
  cohesion, low coupling, and reuse.

45
INDIRECTION

• Problem Where to assign a responsibility, to
  avoid direct coupling between two (or more)
  things? How to de-couple objects so that low
  coupling is supported and reuse potencial remains
  higher?
• Solution Assign the responsibility to an
  intermediate objetc to mediate between other
  componets or services so that they are not
  directly coupled.

46
PROTECTED VARIATIONS

• Problem How to design objects, subsystems, and
  systems so that the variations or instanbility in
  these elements does not have an undesirable
  impact on other elements?
• Solution Identify point of predicted variation
  or instability assign responsibilities to create
  a stable interface around them.

47
IDIOMS

• 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

48
(No Transcript)
49
REFERENCES

• 3 Larman, G., Applying UML and PATTERNS
  Second Edition.