MELJUN CORTES JEDI Slides-4.3 Design Patterns

7/29/2019 MELJUN CORTES JEDI Slides-4.3 Design Patterns

1/32

Software Engineering 1

Design Engineering

Design Patterns

TOPIC THREE


2/32


Design Patterns

They are proven solutions to recurring problems.

They are reusable solutions to common problems.

They describe a way that a problem can be solved; they are

not solutions to problems. They are not FRAMEWORKS.


3/32


Frameworks

They are partially completed software systems that may betargeted at a specific type of application.

Applications are built from frameworks by completing the

unfinished elements and adding application specificelements.

Classes are specialized and implementation created.


4/32


Pattern Documentation

It consists of the following elements:

Name

Context

Problem Solution


5/32


Questions asks when

considering Design Patterns Is there a pattern that addresses a similar problem?

Does the pattern trigger an alternative solution that may bemore acceptable?

Is there a simple solution? Patterns should not be used justfor the sake of it.

Is the context of the pattern persistent with that of theproblem?

Are the consequences of using the pattern acceptable? Are constraints imposed by the software environment that

would conflict with the use of pattern?


6/32


Guidelines for Selecting

Design Patterns Read the pattern.

Study the class structure, participants and collaboration ofthe pattern in detail.

Examine the sample codes to see how to use the pattern. Name the classes of the pattern that are meaningful to the

application.

Define the classes.

Choose application specific names for the operations. Code or implement the operations that perform

responsibilities and collaborations in the pattern.


7/32


Sample Design Pattern

Composite View

Front Controller View

Data Access Object

Model-View-Controller


8/32


Composite View

Context

To make the views manageable by defining a template to handlecommon page elements for a view.

Problem Difficulty of modifying and managing the layout of multiple views due

to duplication of code.

Solution

Use this pattern if the view is composed of multiple atomic sub-

views.

This solution provides a creation of a composite view through theinclusion and substitution of modular dynamic components.


9/32


Composite View Class

Diagram


10/32


Composite View Sequence

Diagram


11/32


Sample Composite View

Template


12/32


Front Controller Design

Pattern Context It provides a centralized controller for managing requests. It

receives all incoming client requests, forwards each request to anappropriate request handler, and presents an appropriate response

to the client. Problem

If there is no centralized controller, problems may occur:

Each view may provide its own system service which may result induplication of code.

Navigation of view is responsibility of the view which may result incommingled view content and navigation.


13/32


Front Controller Design

Pattern Solution A controller is defined to serve as the initial point of contact for

handling request.

Services may include security services (authorization andauthentication), delegating business processing, management ofnext view etc.


14/32


Front Controller Class

Diagram

S end reques t


15/32


Front Controller Sequence

Diagram


16/32


Sample Implementation of

Front Controllerr e quest .setA ttrib ute ( reso urc e . get Me ssageAt tr(),E cto cured .getMes ae));pag}/ / Messa ge Se quenc e 2 exam p le o f t h e Seque n ce D i agra m .

//Di spatc co tdisg;...p ito ddspa c(tpServle Rqestr qet,H teve Rsons epnse,St igpage) trwsj a vax.s ervle t.Ser vle t Exce pti o n , j av a.io.IO Excep tion {Reqg trlt otxt( .eRquestDi pther(p g)d s


17/32


Data Access Object (DAO)

Design Pattern Context It separates resource's client interface from its data access

mechanism.

It allows data access mechanism to change independently of the

code that uses the data.

Problem

Data will be coming from different persistent storage mechanismsuch as a relational database, mainframe, legacy systems, B2Bexternal services

Solution

Use DAO to abstract and encapsulate all access to data source.

It implements the data access mechanism.


18/32



Class Diagram


19/32



Sequence Diagram


20/32


DAO Strategy

Factory Method Strategy

It is used if the underlying storage is not subject to change from oneimplementation to another.

Abstract Factory Pattern

It is used if the underlying storage changes from one implementationto another.


21/32


Factory Method Strategy

Class Diagram


22/32


Abstract Factory Pattern

Strategy Class Diagram

S l I l t ti


23/32


Sample Implementationusing Abstract Factory

Pattern Abstract class DAOFactory// Asrac tclssDAOFactoyp bibtatcasDOatr{//Lp bittcfnlitDFUT=1;p bittcfnlitMSL=2;p bittcfnlitXL=3/ / Th e con cr e t e f a cto r i es s h o u l d im pl emen t t h e se me t ho ds .p b

p u b li c abs tr a c t A t hle t e St a t u s D A O ge tA thle t e S t a tus DA O () ;p u b li c sta ti c DAO F act o r y g e t D A O Fa ct or y(in t w h i chF ac t or y) {s w i tc h ( whi ch F a ct o r y ) {c sDAL: re unnewDefau tAOF ac oy);c sc sd e f au l t : re t u rn n u l l ;}}}

S l I l t ti


24/32



Pattern Default DAOFactory//Dimp o r t ja v a . s q l. *;p bi c lsDe alDOFa tory xend AFcto y{pbl ic tt cfnlSr nDR VRu.dc ob.dbcOdbcDiep u b li cs t at i c fi na l Str i ng U R L= j d b c : od bc :A ngBu l i l i t Lig a

/methodforconn ctionp bi c ttcC neton reate onec in)

/ Ue D IEan Roc eate onec in}p bitltDOgttltDO){r treealAheeA(;}..}

S l I l t ti


25/32



Pattern AthleteDAO Interfacepu biin terfceAthleteDp bp bpb dit thl( thl te;p u b li cA t hl e te fi n dA t h let eR e c ord ( Str i n g s e a r c h Cr it er ia);p bi coSts el cAhle te(Str nse ar hrter a)...}

S l I l t ti


26/32



Pattern AthleteDAO Implementationimp raasl*

p bi c lsDe f alAhle t eDAO mlem tlet DApub iDefaulAthleteDAO(){/iz}pb nse tAtt (At leta){/ /

// eurns0fsuccessful.}...}

Sample Implementation


27/32



Pattern Athlete Transfer Objectpbclt{p ri va te in t a t hl ete I D;p ri va te St ri n g l ast N am e ;pr iaeStrinfirstName;...

/sdmspbd set thlI (inID

athl eeDI;}

p ub li c int g e t At hle t eI D ()rtntI}}


28/32



Design Pattern Context The application presents contents to users in numerous pages

containing data.

Problem

If there is need to support multiple types of users with multiple typesof interfaces.

Forces that drives the use of this pattern:

The same enterprise data needs to be accessed by different views.

The same enterprise data needs to be updated through differentinteractions.

The support of multiple types of views and interactions should notimpact the components that provide the core functionality of theenterprise application.


29/32



Design Pattern Solution It is widely used design pattern for interactive applications.

It divides the functionality among objects involved in maintaining andpresenting data to minimize the degree of coupling between the

objects.

It divides the application into three:

Model which represents the data and the business rules that governaccess to and updates to this data.

View which renders the contents of a model.

Controller which translates interactions with the view into actions to beperformed by the model.


30/32



Design Pattern DiagramMODEL-represents

enterprise data-represents

business rules-maintains application

states

CONTROLLER

-defines applicationbehavior

-routes user commandsto Model updates-selects Views for

presentation

VIEW

-renders the Model-accesses enterprise data-relays user actions to the

Controller

Query State

Change State

Select View

Notify Changes

User Actions

Method Call

Event


31/32


MVC Strategies

For web-based clients such as browsers, use Java ServerPages (JSP) to render the view, Java Servlet as controllerand Enterprise Java Beans (EJB) components as model.

For centralized controllers, instead of having multiple

servlets as controller, a main servlet is used to make controlmore manageable. The Front Controller Design Pattern canbe a useful pattern for this strategy.


32/32


Summary

Design Pattern

Design Pattern Document Elements

Sample Design Pattern

Composite View Design Pattern Front Controller Design Pattern

Data Access Object (DAO) Design Pattern

Model-View-Controller Design Pattern

Date post:	03-Apr-2018
Category:	Documents
Upload:	meljun-cortes-mbampa
View:	225 times
Download:	0 times

MELJUN CORTES JEDI Slides-4.3 Design Patterns

Documents