41.DesignPatterns-Part1

8/7/2019 41.DesignPatterns-Part1

1/33

Object-Oriented Software EngineeringPractical Software Development using UML and Java

Design Patterns

Sources:

Chapter 6: Using Design Patterns, and

Chapter 30 (parts) Designing the Logical Architecture with PatternsCraig Larmans Text: Applying UML and Patterns, Chaps: 16, 17, 22, & 23.


2/33

Lethbridge/Laganire 2001 Chapter 6: Using design patterns 2

Patterns

Architectural: - related to the large-scale and coarse-grained design, and typically applied during the early

iterations (the elaboration phase) when the major

structures and connections are established.

Design Patterns: - related to the small and medium-scale

design of objects and frameworks. Applicable to

designing a solution for connecting the large scale

elements defined via architectural patterns, and during

detailed design work for any local design aspect.(Sometimes also known as architectural patterns).


3/33


Sample Titles

The Faade pattern, which can be used to provide the interface

from one layer to the next

Singleton pattern to ensure global access to a single instance of a

class.

Information Expert (Expert); Adaptor; Creator; Observer;

Low Coupling; High Cohesion; Controller; etc. etc.

Design Patterns are often organized into different categories too.

Most of these notes from the first two lectures on Design Patterns

are taken directly from Larmans text.


4/33


Preview:

Want to look at more class diagrams static.

But we want to look at recurring groupings of classes

that are regularly used to address common problems.

Want to take advantage of experiences of others and create a better,

more resilient design.

Want to usepatterns that assist us in separating concerns (abstraction-

occurrence, observer, player-role);

patterns used to better create class hierarchies of instances;

patterns in which one method simply calls another method

in another class (have you seen this??);

patterns where you use delegation to gain access to facilities

in one or more other classes (Adaptor, Faade, Proxy);

patterns that help protect other objects from unanticipated access

(immutable and read-only interfaces).


5/33


Preview: continued.

We will study several of the most often used patterns GRASP Patterns, and

Gang of Four (GoF) Patterns

Please recognize that in some cases, you will note thatyou may be already doing some of these things.

You may now see more rationale and more formalreasoning

In all cases, the patterns will be most helpful as we striveto design objects.


6/33


One more look before we look at design patterns:

Design Patterns are groups of objects designed to

support simply a good object design with emphasis on

those features that constitute good object design, such

as

design that yields high cohesion of our objects, lowcoupling between our objects, which, among other

things, fosters more likely reuse

It is one thing to create an objectit is quite another tocreate the right object for the right situation.


7/33


Object design is NOT a simple undertaking and involves, as alldesign does, making decisions. Good object design involves theassignment of responsibilities, and there are patterns that can assistus.

Deciding what methods belong where and how objects interact iscritically important and NOT trivial.

All this is really at the heart of what it means to develop an object-oriented system, not merely the drawing of domain modeldiagrams, package diagrams, etc.

We will thus look at a number of object patterns in attempts todevelop better designs.


8/33


6.1 Introduction to Patterns (from OOSE book)

The recurring aspects of designs are called design patterns.

A pattern is the outline of a reusable solution to a general

problem encountered in a particular context

Many of them have been systematically documented for all software

developers to use A good pattern should

Be as general as possible

Contain a solution that has been proven to effectively solve

the problem in the indicated context.

Studying patterns is an effective way to learn from the experience ofothers


9/33


Introduction Suggestive Names

Patterns have names and the names are suggestive

The names can be used in our vocabulary to

communicate design intentions.

Here again, naming a pattern is using an abstraction

of the details of that pattern.


10/33


Grasp Patterns

General Responsibility Assignment Software Patterns.

GRASP Patterns is redundant but it stuck.

Recognize that according to Craig Larman:

1. The skillful assignment of responsibilities isextremely important in object design,

2. Determining the assignment of responsibilities oftenoccurs during the creation of interaction diagramsand certainly during programming.

Larman, p. 219.

Please note that much of the following information istaken directly from Larmans book.


11/33


GRASP Patterns

Note:

A Design Model may have hundreds or

thousands of software classes and hence hundreds or

thousands of responsibilities to be fulfilled.

During object design, when interactions between

objects are defined, we make choices about the

assignment of responsibilities to software classes..


12/33


1. Information Expert (or Expert) (GRASP Pattern)

Start by assigning responsibilities by clearly stating the

responsibility:

Who shouldberesponsible forknowingthegrandtotal of

asale?

So, who has the information needed to determine the

total?


13/33


Expert (Grasp Pattern)

Next question: look in Domain Model or Design Model?

Domain Model contains conceptual classes of the real-world domain;

Design Model contains the software classes.

First choice: If we have relevant classes in theDesign Model, choose this first.

Second choice: look into Domain Model andattempt to use (or expand) its representations toinspire the creation of corresponding designclasses.


14/33


Expert (Grasp Pattern)

Continuing

Assume we are just starting and we have no real Design

Model. So look to Domain Model and we find Sale.

Sale

date

time

SalesLineItem

quantity

Product

Specification

description

price

itemID

1

*

* 1

Described by

Contains


15/33


Add a Sale class to the Design Model, and give it

the responsibility of knowing its total, expressed

with a method named getTotal.

This approach supports a low representational gap, in

which the software design of objects appeals to our

concepts of how the real domain is organized.

We now have:


16/33


t := getTotal(): Sale

:Sale

date

time

getTotal()New method ------

Our first design class:


17/33


What info do we need in the grand total?

We need to know about all the SalesLineItem instances of a

sale and sum their subtotals.

A Sales instance contains these; thus by Information

Expert, Sale is the suitable class for this responsibility.

But it needs helpand we are not done.


18/33


What information is needed to determine the line itemsubtotals?

We need: SalesLineItem.quantity and

ProductSpecification.price

The SalesLineItem knows its quantity (is an attribute) andits associated ProductSpecification (via association);

Therefore, by Expert,S

alesLineItem should determine thesubtotal; it is the information Expertin this case.

So, now what do we have?


19/33


Consider:

t := getTotal(): Sale : SalesLineItem

1 *: st := getSubtotal()

:Sale

date

time

getTotal()

:SalesLineItem

quantity

getSubtotal()

Well, we now have:

Note: we have added a responsibility,

getSubtotal() to SalesLineItem

We have also added another class to our Design Model


20/33


Continuing:

To fulfill the responsibility of knowing and answering the

subtotal, a SalesLineItem needs to know the product price.

The ProductSpecification is an information experton

answering its price (it is an attribute ofProductSpecification); thus we need a message sent to it

asking for the price.

This is shown on the next slide.and we end up with:


21/33


Consider:

See the design classes and an abbreviated

communications (collaboration) diagram.

t := getTotal(): Sale : SalesLineItem

: Product

Specification

1 *: st := getSubtotal()

1.1: p := getPrice()

Sale

date

time

getTotal()

SalesLineItem

quantity

getSubtotal()

Product

Specification

description

price

itemID

getPrice()

Please note that the responsibilities were decided upon whiledrawing an interaction diagram.

The principle by which each responsibility was assigned was

Information Expert placing it with the object that had the

information needed to fulfill it.


22/33


Continuing

Information Expert is frequently used in assigning responsibilities.

It is thee guiding principles and continuously used in object design.

Note that the fulfillment of responsibilities often requires spanning

several different classes.

This implies that there are several partial information experts

who collaborate in the task.

Fundamentally, they do things relative to the information

they know.


23/33


But be careful:

Now, running Expert into the ground..

Who should be responsible for saving Sale in a database?

Clearly, much of the information is in the Sale object andthus by Expert an argument could be made to put thatresponsibility in the Sale class.

But, by extension, then, EACH class would have its own

services to save itself in the database.

This, of course, leads to problems in cohesion andcoupling, and duplication.


24/33


Being careful with Expert

What does all this mean? If we were to do this:

Sale would have to now contain logic related to database handling, suchas related to SQL and JDBC.

Class is NOW no longer focused on just pure application of logic of

being a sale; it now has other kinds of responsibilities, which lowersits cohesion!

The class must be coupled to the technical database services of anothersubsystem, such as JDBC services, rather than just being coupled toother objects in the domain layer of software objects, which raises itscoupling.

And, it is likely that similar database logic would be duplicated in manypersistent classes.


25/33


Being careful with Expert - final

These problems violate a basic architectural principle: design forthe separation of major system concerns.

Keep application logic in one place (such as the domain

software objects);

Keep database logic in another place (such as a persistence

services subsystem), etc. rather than intermingling

different system concerns in the same component.

Supporting a separation of major concerns improves coupling

and cohesion in a design.

Thus, even though by Expert there could be some justification toput the responsibility for database services into the Sale class, forother reasons, (usually coupling and cohesion), it is a poor design.


26/33


Benefits of Expert:

Benefits:

1. Information encapsulation is maintained,since objects use their own information to fulfilltasks.

This usually supports low coupling, which leads toa more robust and maintainable system. (LowCoupling is also a GRASP pattern).

2. Behavior is distributed across the classes that

have the required information thus encouragingmore cohesive lightweight class definitions thatare easier to understand and maintain. Highcohesion is usually supported. Reuse potential up.


27/33


The Creator Pattern (a GRASP Pattern)

Problem: Who is responsible for creating new instances of some

class?

Solution: Assign class B the responsibility to create an instance of

class A if one or more of the following is true:

Baggregates A

BcontainsA

Brecords instances of A objects

Bclosely usesA objects

Bhastheinitializingdata that will be passed to A

when it is created (thus B is an Expert withrespect to creating A)

If more than one option applies, prefer a class B which aggregatesor

contains class A.


28/33


Creator - continued

This is a very common activity in OO systems.

This is, then, a general principle for the assignment of

creation activities.

This approach can result in low coupling, increased

clarity, encapsulation, and reusability.


29/33


Creator - Example

In Craig Larmans Point of Sales application, we have

the previously described class relationships.

Sale

date

time

getTotal()

SalesLineItem

quantity

getSubtotal()

Product

Specification

description

price

itemID

getPrice()

1

*

* 1

Described by

Contains

Who should be responsible forcreating a SalesLineItem instance?

In Creator, we look for a class that aggregates, contains, records SalesLineItem instances.


30/33


Creator - example

Here, clearly, Sales contains or aggregates many

SalesLineItem instances.

Since a Sale contains many SalesLineItem objects, the

Creator pattern suggests that Sale is a good candidate tohave the responsibility of creating SalesLineItem

instances.

See next slide: Clearly a Salecontains (aggregates)SalesLineItem objects. Thus the Creator pattern

suggests that Sale is a good candidate for this

responsibility.


31/33


Abbreviated Sequence Diagram:

:Register

:SalesLineItem

:Sale

makeLineItem(quantity)

create (quantity)

The assignment of responsibilities requires that a makeLineItem method be defined in Sale.

Once again, the context for these decisions was while drawing the interaction diagram.

The method section of a class can then summarize the responsibility assignment results concretely

realized as methods.


32/33


Benefits ofCreator Pattern:

Object creation is a very common activity, and we want acreator that needs to be connected to the created object;This naturally supports now coupling too.

Sometimes a creator is found by looking for the class thathas the initializing data that will be passed in duringcreation.

This is actually an example of the Expert pattern.Initializing data is passed in during creation via some kind

of initialization method, like a Constructor, or, .

Please note that these words/drawings are almost verbatimfrom Craig Larmans textbook.


33/33


More Grasp Patterns Coming

We will next look at

Polymorphism a Grasp Pattern and

Controller another Grasp Pattern.

41.DesignPatterns-Part1

Documents

Transcript of 41.DesignPatterns-Part1