GRASP: 더 많은 객체에 책임 할당

GRASP: 더 많은 객체에 책임 할당

Chapter 25Applying UML and Patterns

Craig Larman

http://cespc1.kumoh.ac.kr/index.html

2금오공과대학 컴퓨터공학부 컴퓨터공학전공

Objectives

Learn to apply the following GRASP patterns: Polymorphism

Pure Fabrication

Indirection

Protected Variations


Introduction

GRASP stands for General Responsibility Assignment Software Patterns. It is a learning aid of fundamental principles by which

responsibilities are assigned to objects and objects are designed.

We already learned about the first five GRASP patterns: Information Expert, Creator, High Cohesion, Low

Coupling, Controller


Introduction

In this presentation we will look at four new GRASP patterns: Polymorphism

Indirection

Pure Fabrication

Protected Variations


25.1 Polymorphism

Problem Who is responsible when behaviors vary by type?

How to handle alternatives based on type?

– If – then – else or case statements requires source code modification.

How to create pluggable software components?

– Server replacement without affecting the client


Polymorphism

Solution Polymorphism is a fundamental principle in designing how

a system is organized to handle similar variations.

When related alternatives or behaviors vary by type (class), assign responsibility for the behavior-using polymorphic operations-to the types for which the behavior varies.

Do not use conditional logic to perform varying alternatives based on type

이전에 사용하던 솔루션은 ? if then else #IFDEF ASGOODASTAX_TAX_CALC


UML Notation

UML Notation for Interfaces and Return types


Example

NextGen POS application supporting multiple Tax Calculators is a polymorphic operation.


Discussion Polymorphism is a fundamental principle in designing

how a system is organized to handle similar variation.

Contraindications Developers may indulge in speculative “future-

proofing” against unknown possible variations.

Benefits Extensions required for new variations are easy to

add.

New implementation can be introduced without affecting clients.


26.2 Pure 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 Information Expert are not appropriate?

There are many situations in which assigning responsibilities only to domain concepts leads to problems in terms of poor cohesion or coupling.

Solution Assign a highly cohesive set of responsibilities to an

artificial class that does not represent a problem domain concept - something made up, in order to support high cohesion and low coupling and reuse.


Pure Fabrication: Example

To save the Sale instances in a relational database. By Information Expert, Sale class itself have the

responsibility But the above solution leads to:

Low Cohesion: database tasks are not related to the concept of sale.

High Coupling: The Sale class is coupled to the relational database interface.

Low Reusability: The general task of saving to the database may be needed by other classes. Assigning it to Sale class causes poor reuse and lots of duplication.


Pure Fabrication: Example

Solution Create a new class that is solely responsible for saving objects. This class is a Pure Fabrication.

Ex. The Sale remains well-designed, with high cohesion and low

coupling. The PersistentStorage class is itself relatively cohesive, having the

sole purpose of storing or inserting objects in a persistent storage medium.

The PersistentStorage class is a very generic and reusable object.


Discussion

Objects can be divided into Representational decomposition

– Software classes which is related to a thing in a domain

– Ex. Sale, TableofContents Behavioral decomposition

– Responsibilities by grouping behaviors or by algorithm that is not related to a real-world domain concept

– Ex. TableofContentsGenerator

Many existing OO design patterns are example of Pure Fabrications


Benefits High Cohesion is supported

– because that only focuses on a very specific responsibility are factored into a fine grained class set of related tasks.

Reuse potential may be increased

– because of the presence of fine grained pure fabrication classes.

Contraindications If overused,

– Pure Fabrication could lead to too many behavior objects

– If we overuse pure fabrication, symptom is that most of the data inside the objects is being passed to other objects.

Related patterns Most of the GoF patterns are pure fabrication


25.3 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 potential remains higher? Solution

Assign the responsibility to an intermediate object to mediate between other components so that they are not directly coupled.


Indirection: Example

Tax Calculator Adapter act as intermediaries to the external tax calculators.

By adding a level of indirection and adding polymorphism,

the adapter objects protect the inner design against variations in the external interfaces.


Indirection: Example

Persistent Storage The Pure Fabrication example

– decoupling the Sale from the relational database services

A PersistentStorage class is also an example of Indirection.

The PersistentStorage acts as a intermediary between the Sale and the database.


Discussion Just as many existing design patterns are

specializations of Pure Fabrication, many are also specializations of Indirection.

Adapter, Facade, and Observer are examples [GHJV95].

Many Pure Fabrications are generated because of Indirection

The motivation for Indirection is usually Low Coupling

Benefit Low Coupling between components.


25.4 Protected Variations

Problem How to design objects, subsystems and systems so that

the variations or instability in these elements does not have an undesirable impact on other elements?

Solution Identify points of predicted variation or instability; assign

responsibilities to create a stable interface around them.

Example External tax calculator problem and its solution with

Polymorphism illustrate Protected Variations (Figure 22.1).

Using polymorphism with various ITaxCalculatorAdapter implementations, protection within the system from variations in external APIs is achieved.


Discussion

was first published by Cockburn

Mechanisms Motivated by PV PV is a root principle motivating most of the

mechanisms to provide flexibility and protection from variations.

Later, one learns techniques such as

– rule-based languages, rule interpreters, reflective and metadata designs, virtual machines, and so forth


Protected Variations: Mechanisms

1. Core Protected Variation Data encapsulation, interfaces, polymorphism, indirection.

2. Data Driven Design "parameterize" a system in some way at runtime.

– Reading codes, class file paths, class name.

style sheets, metadata for object-relational mapping,

reading windows layout, property file (registry)

3. Service Lookup Clients are protected from variations in the location of

services

JNDI, LDAP, Java’s Jini, UDDI.


Protected Variations: Mechanisms

4. Interpreter-Driven Designs rule interpreters that execute rules read from an external source.

5. Reflective or Meta-Level Designs java.beansJntrospector The system is protected from the impact of logic or external code

variations by reflective algorithms that use introspection and meta-language services.

6. Uniform Access Some languages ada, Eiffel, and C# support a syntactic construct

so that both a method and field access are expressed the same way.

class MyClass {

private var x:Number;

function MyClass () { }

public function get x () : Number { return x; }

public function set x (value:Number) { x = value; }

}


7. The Liskov Substitution Principle (LSP) Software methods that work with a class T should work with all

subclasses of T.

8. Structure-Hiding Design Don't Talk to Strangers!

Avoid creating designs that traverse long object structure paths and send messages (or talk) to distant, indirect (stranger) objects.

messages should only be sent to the following objects:1. The this object (or self).2. A parameter of the method.3. An attribute of this.4. An element of a collection which is an attribute of this.5. An object created within the method.


Example

In new systems in early iteration, it is not stable


Protected Variations: Example

In the external tax calculator problem, the point of instability is the different interfaces to the external tax calculators.

By adding a level of indirection, an interface, and using polymorphism with various adaptors, protection within the system from variations in external calculator APIs is achieved.


Protected Variations: Contraindications

Two change Variation point: in the existing requirement

Evolution point: may arise in the future

The cost of “future-proofing” at evolution point may outweigh the cost incurred by a simple design that is reworked as necessary.

Example Script and interpreter in a mobile environment


Benefits

Extensions required for new variations are easy to add.

New implementations can be introduced without affecting clients.

Coupling is lowered.

The impact or cost of changes be lowered.

GRASP: 더 많은 객체에 책임 할당

Documents

Transcript of GRASP: 더 많은 객체에 책임 할당