Design Pattern doc

CHƯƠNG 8: Design Pattern... Information Expert or Expert Solution: Assign a responsibility to the information expert - the class that has the information necessary to fulfill the respon

Trang 1

CHƯƠNG 8: Design Pattern

Trang 2

N i dung ô

 Coupling là gì?

 Cohesion là gì?

 Pattern là gì?

 GRASP là gì?

Trang 3

Coupling là gì?

 Coupling là 1 cách đ đo lể ừơng xem 1 ph n t ầ ửkhi được k t n i thì nó có kh năng “hi u ế ố ả ể

bi t” đ n m c nào hay hoàn toàn ph thu c ế ế ứ u ô

vào các ph n t khác Ph n t có th là class, ầ ử ầ ử ể

subsystem, system…

 M t ph n t có coupling th p (low coupling) ô ầ ử ấ

ngh a là nó không ph thu c nhi u vào các ĩ u ô ê

ph n t khác ầ ử

Trang 4

Coupling là gì?

 M t l p có coupling cao s ph thu c vào ô ơ ẽ u ô

nhi u l p khác Các l p này là không nên dùng ê ơ ơvì:

◦ Nh ng thay đ i trong các l p có liên quan s ữ ổ ơ ẽlàm cho l p này c ng b thay đ i theoơ ũ ị ổ

◦ Khó hi u khi chúng b cô l pể ị ậ

◦ Khó dùng l i vì nó đòi h i s hi n di n c a ạ ỏ ự ệ ệ u

1 s l p mà nó ph thu c vàoố ơ u ô

Trang 5

Cohesion là gì?

 Coupling đ c p đ n s tê ậ ế ự ương tác gi a các đ i ữ ố

tượng thì cohesion đ c p đ n s tê ậ ế ự ương tác

bên trong 1 đ i tố ượng

 Cohesion là 1 cách đo lường đ xem các ể

nhi m v c a 1 ph n t có quan h ch t ch ệ u u ầ ử ệ ặ ẽ

v i nhau nh th nào?ơ ư ế

 M t ph n t có trách nhi m tô ầ ử ệ ương đ i cao, và ốkhông ph i làm quá nhi u vi c đả ê ệ ược xem là có cohesion cao (high cohesion)

Trang 6

Cohesion là gì?

 M t l p có low cohesion khi nó làm nhi u ô ơ ê

vi c không liên quan nhau hay làm quá nhi u ệ ê

vi c Nh ng l p này là không nên dùng vì:ệ ữ ơ

Trang 7

Cohesion là gì?

 Method cohesion: là method ch đ m nhi m 1 ỉ ả ệ

ch c năng hay 1 nhi m v Thông thứ ệ u ường cách

đ t tên c a nó c ng ng m nói lên ch c năng, ví ặ u ũ ầ ứ

d method chon_nha_cung_cap(), Tinh_tong()u

 Class cohesion: các thu c tính và method c a ô u

l p ph i có m c đ cohesion cao, ngh a là ơ ả ứ ô ĩ

chúng ph i đả ược dùng b i chính các method ở

trong class hay ch ch a các method ph c v ỉ ứ u u

Trang 8

Các m c đ cohesion ứ ô

1. Very low cohesion: m t class ph i t mình ô ả ự

làm nhi u vi c trong nh ng mi n ch c năng ê ệ ữ ê ứhoàn toàn khác nhau

Trang 9

l p này thành 1 h các l p cùng chia x nhau ơ ọ ơ ẻ

Trang 10

Các m c đ cohesion ứ ô

 High cohesion: l p có nhi m v v a ph i ơ ệ u ừ ả

(moderate responsibilities) trong cùng 1 vùng

ch c năng và h p tác v i các l p khác đ hoàn ứ ợ ơ ơ ểthành nhi m v ệ u

 Ví d : l p RDBInterface ch có 1 ph n nhi m u ơ ỉ ầ ệ

v trong vi c tu ệ ương tác v i database Nó ơ

tương tác v i hàng tá các l p khác đ khôi ơ ơ ể

ph c và l u tr d li u u ư ữ ữ ệ

Trang 11

Quy lu t Cohesion và Coupling ậ

 Cohesion kém thì thường sinh ra coupling kém và ngượ ạc l i

 Cohesion và couling được ví nh ư âm và du ng ơ(yin and yang) c a software engineeringu

Trang 13

Pattern là gì?

 Trong th c t có r t nhi u lự ế ấ ê ược đ class có ô

c u trúc gi ng nhau Pattern đấ ố ược xem nh là ư

gi i pháp hay cách th c ả ứ đ gi i quy t bài toán ể ả ế

 Khái ni m v pattern trong thi t k ph n ệ ê ế ế ầ

m m đu c vay mê ợ ượ ừn t ngành ki n trúc xây ế

d ng n i mà các pattern tr giúp r t nhi u ự ơ ợ ấ ê

cho các ki n trúc s khi làm vi c v i các c u ế ư ệ ơ ấtrúc ph c t pứ ạ

Trang 14

Pattern là gì?

 M t pattern khi đô ược áp d ng vào1 ng c nh u ữ ả

m i s đ a ra các khuy n cáo ơ ẽ ư ế

(recommendation) làm th nào đ áp d ng và ế ể uhòa h p nó vào tình hu ng m iợ ố ơ

 “A pattern is a named problem/

solution pair that can be applied in new context, with advice on how to apply it in novel situations and discussion of its trade-offs”

Trang 15

 GRASP (General Responsibility Assignment

Software Patterns) bao g m nhi u pattern mô ô ê

t các nguyên t c c b n trong vi c thi t k ả ă ơ ả ệ ế ế

đ i tố ượng và gán nhi m v cho đ i tệ u ố ượng

 Hi u và áp d ng các nguyên t c GRASP trong ể u ă

quá trình t o lạ ược đ tô ương tác là r t quan ấ

tr ng giúp thi t k thành công ph n m m ọ ế ế ầ ê

hương đ i tố ượng

Trang 16

 Khi thi t k đ i tế ế ố ượng, c n ch n l a xem ầ ọ ự nhi m ệ

v nên gán cho đ i tu ố ượng nào là phù h p h n ợ ơ

N u gán h p lý, h th ng s tr nên d hi u, d ế ợ ệ ố ẽ ở ễ ể ễ

b o trì và m r ng.ả ở ô

Trang 18

Information Expert (or Expert)

 Solution: Assign a responsibility to the

information expert - the class that has the

information necessary to fulfill the

responsibility

 Problem: What is a general principle of

assigning responsibilities to objects?

 G i t t pattern này là IEọ ă

Trang 19

Case study 1: L p nào bi t t ng tr giá ơ ế ổ ị

 N u có m t s l p ế ô ố ơ c n bi t t ng tr giá ầ ế ổ ị c a 1 u

l n bán Câu h i đ t ra là l p nào có nhi m v ầ ỏ ặ ơ ệ ucho bi t t ng tr giá m t l n bán ế ổ ị ô ầ

 Theo IE c n tìm xem có l p nào ch a thông tin ầ ơ ứ

c n thi t đ xác đ nh t ng s hay không? ầ ế ể ị ổ ố

Chúng ta nên tìm các l p trong mô hình domain ơhay mô hình thi t k ế ế

Trang 20

Case study 1: L p nào bi t t ng tr giá ơ ế ổ ị Case study 1: L p nào bi t t ng tr giá ơ ế ổ ị

1. Trươc h t tìm các l p thích h p trong mô ế ơ ợ

hình thi t k ế ế

2. N u không tìm th y, thì tìm các l p trong mô ế ấ ơ

hình domain và c s d ng các l p trong mô ố ử u ơhình domain đ t o l p các l p tể ạ ậ ơ ương ng ứ

trong mô hình thi t k ế ế

Trang 21

Gi s chúng ta ch v a m i b t đ u vi c thi t ả ử ỉ ừ ơ ă ầ ệ ế

k và ch a có gì nhi u trong mô hình thi t k ế ư ê ế ếChúng ta s tìm ki m trong mô hình domain ẽ ế

đ tìm ra l p IE và l p đó chính là ể ơ ơ Sale Chúng

ta thêm vào mô hình thi t k l p ph n m m ế ế ơ ầ ê

m i c ng có tên g i là Sale và gán cho nó ơ ũ ọ

nhi m v bi t “knowing total” thông qua ệ u ế

method getTotal

Trang 22

Trang 23

 Thông tin gì c n bi t đ xác đ nh ầ ế ể ị thành ti n ê

(subtotal) c a m i m t hàng (line item)? u ỗ ặ  c n ầ

ph i bi t s lả ế ố ượng (quantity) và đ n giá ơ

(price)

 Theo mô hình nghi p v , thì l p SalesLineItem ệ u ơ

bi t s lế ố ượng (quantity) và thông tin hàng

(ProductSpecification) tương ng Vì v y, ứ ậ

SalesLineItem xác đ nh đị ược thành ti n ê

Trang 24

Case study 1: L p nào bi t t ng tr giá ơ ế ổ ị

 Trong lược đ tô ương tác ,đ nh n thành ti n ể ậ ê

c a m i m t hàng thì l p Sale c n g i thông u ỗ ặ ơ ầ ử

đi p get-Subtotal cho m i l p SalesLineItem và ệ ỗ ơtính t ng trên k t qu mà nó nh n đổ ế ả ậ ược

Trang 25

 Đ hoàn thành nhi m v bi t và tr l i thành ể ệ u ế ả ờ

ti n (subtotal), l p LineItem c n bi t đ n giá ê ơ ầ ế ơ

s n ph m ả â

 L p ProductSpecification là IE s giúp tr l i v ơ ẽ ả ờ ê

đ n giá Và l p này c n m t thông báo đơ ơ ầ ô ược

g i đ n đ h i giá ử ế ể ỏ



Trang 26

Trang 27

 Tóm l i đ hoàn t t nhi m v bi t và tr l i ạ ể ấ ệ u ế ả ờ

t ng tr giá bán, ba nhi m v đổ ị ệ u ược gán vào ba

l p thi t k nh sau:ơ ế ế ư

Lớp thiết kế

(Design class) Nhiêêm vu

Sale Biết tổng trị giá (sale total)

Biết thành tiền môêt măêt hàng

Trang 28

Information Expert

 IE thường được dùng trong vi c gán nhi m v ệ ệ u(responsibilitiy);

 Nó là 1 nguyên t c hă ương d n c b n đẫ ơ ả ược

dùng liên t c trong thi t k object u ế ế

 Nó di n đ t nh n th c ("intuition“) chung r ng ễ ạ ậ ứ ằobject làm các vi c có liên quan đ n thông tin ệ ếchúng có

 Vi c hoàn thành nhi m v thệ ệ u ường yêu c u ầ

Trang 29

 Solution: Assign class B the responsibility to

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

◦ B aggregates A objects.

◦ B contains A objects.

◦ B records instances of A objects.

◦ B closely uses A objects.

◦ B has the initializing data that will be passed to A

when it is created

Trang 30

 Problem: Who should be responsible for

creating a new instance of some class?

 The creation of objects is one of the most

common activities in an object-oriented system Consequently, it is useful to have a general

principle for the assignment of creation

responsibilities

 Assigned well, the design can support low

Trang 31

◦ B s d ng th ử u ườ ng xuyên các đ i t ố ượ ng A

◦ B có các d li u kh i t o c n đ ữ ệ ở ạ ầ ượ c chuy n cho A khi ể

A đ ượ c kh i t o ở ạ

 B là 1 creator c a Au

 Problem : Ai nên có trách nhi m t o 1 instance ệ ạ

m i cho 1 s class?ơ ố

Trang 32

Case Study: L p nào t o đi n hình c a ơ ạ ể u

Trang 33

SalesLineItem

Trang 34

SalesLineItem

 T mô hình domain, cho th y l p Sale ch a ừ ấ ơ ứ

nhi u đ i tê ố ượng SalesLineltem, do đó Creator

đ ngh Sale là 1 ng viên t t cho nhi m v ê ị ứ ố ệ u

t o các instance c a SalesLineltem ạ u

 D n đ n vi c v lẫ ế ệ ẽ ược đ tô ương tác nh sauư

Trang 35

L ượ c đ tu n t ô ầ ự

Trang 36

 Vi c gán nhi m v này d n đ n vi c là ph i có ệ ệ u ẫ ế ệ ảmethod makeLineItem() trong l p Saleơ

 Vi c xem xét và gán nhi m v đa đệ ệ u ược làm

trong lúc v lẽ ược đ tô ương tác

Trang 37

 Creator hương d n vi c gán responsibility có ẫ ệ

liên quan đ n vi c t o các object M c đích c ế ệ ạ u ơ

b n c a Creator là tìm 1 class c n k t n i t i ả u ầ ế ố ơobject đượ ạc t o trong b t k s ki n nào ấ ỳ ự ệ

 Các container, hay class d ng ghi chép l u tr ạ ư ữ

đ u là ng viên t t đ làm creator ê ứ ố ể

Trang 38

 Đôi khi l p creator đơ ược tìm th y trong lúc ấ

tìm ki m l p ch a d li u ban đ u c n đế ơ ứ ữ ệ ầ ầ ược chuy n cho l p s để ơ ẽ ượ ạc t o

 Ví d : gi s instance c a Payment c n có giá u ả ử u ầ

tr kh i đ u (initial value) là t ng s ti n bán ị ở ầ ổ ố ê

khi nó đượ ạc t o Vì Sale bi t t ng s này nên ế ổ ố

Sale là ng viên t t đ tr thành creator c a ứ ố ể ở uPayment

Trang 39

Low Coupling

 Solution gán responsibility sao cho coupling

v n gi đẫ ữ ượ ở ức m c th pấ

 Problem Làm th nào đ làm cho s ph ế ể ự u

thu c th p, nh ng nh hô ấ ữ ả ưởng khi thay đ i ổ

th p, và kh năng s d ng l i tăng (How to ấ ả ử u ạ

support low dependency, low change impact,

and increased reuse?)

Trang 40

("records“) các thanh toán (Payment) trong th ế

gi i th c nên Creator đ c Register là ng ơ ự ê ử ứ

viên t o Payment.ạ

Ti p đó Register c ng c n g i message ế ũ ầ ử

Trang 41

Cách 1: gán trách nhi m cho Register ệ

Việc gán responsibility này đã làm cho lớp

Trang 42

Cách 2: gán trách nhi m cho Sale ệ

Trang 43

Ch n l a thi t k ọ ự ế ế

 Thi t k nào h tr Low Coupling? ế ế ỗ ợ

 Trong c 2 trả ường h p, ta đ u gi s là Sale ợ ê ả ử

Trang 44

Ch n l a thi t k ọ ự ế ế

 Trường h p đ c bi t c a Low Coupling là khi ợ ặ ệ ukhông có 1 coupling nào gi a các class Đi u ữ ê

này c ng không t t vì theo hũ ố ương đ i tố ượng

thì các đ i tố ượng c n giao ti p v i nhau thông ầ ế ơqua các message N u Low Coupling đế ược th c ự

hi n quá tri t đ thì s t o ra 1 thi t k ệ ệ ể ẽ ạ ế ế

nghèo nàn, các đ i tố ương không couple s làm ẽ

vi c nh 1 kho d li u đ n thu n ho c chúng ệ ư ữ ệ ơ ầ ặ

ph i t làm h t m i vi c ả ự ế ọ ệ

Trang 45

High Cohesion

 Solution: gán nhi m v (responsibility) sao ệ u

cho cohesion v n gi m c cao ẫ ữ ở ứ

 Problem Làm th nào v n qu n lý đế ẫ ả ược đ ô

ph c t p (complexity)? ứ ạ

Trang 46

Ví du

 Trong ví d tru ươc đ t o 1 instance c a ể ạ u

Payment và k t h p nó v i Sale Class gì nên ế ợ ơ

làm vi c này? ệ

 Vì Register ghi chép l i Payment nên creator đ ạ êngh Register là 1 ng viên cho vi c t o ị ứ ệ ạ

Payment Sau đó Register g i message ử

addPayment cho Sale cùng v i tham s là ơ ố

payment m i v a t o ơ ừ ạ

Trang 47

Ví du

 Register đang nh n trách nhi m hoàn thành ậ ệ

thao tác h th ng makePayment N u ch xét ệ ố ế ỉtrong ph m vi ví d này thì nhi m v này có ạ u ệ u

th ch p nh n để ấ ậ ược, nh ng n u ti p t c gán ư ế ế ucho Register nhi u vi c h n, nó s tr nên quá ê ệ ơ ẽ ở

t i và không còn cohesion n a ả ữ

Trang 48

 Solution: gán nhi m v nh n và qu n lý m t ệ u ậ ả ô

thông báo s ki n h th ng cho m t l p có ự ệ ệ ố ô ơ

m t trong hai d ng sau:ô ạ

◦ Đ i di n cho c h th ng, thi t b hay h th ng con ạ ệ ả ệ ố ế ị ệ ố (boundary class)

◦ Đ i di n cho m t k ch b n use case mà trong đó có ạ ệ ô ị ả

s ki n h th ng x y ra, l p này th ự ệ ệ ố ả ơ ườ ng đ ượ c đ t ặ tên là <UseCaseName>Handler,

<UseCaseName>Coordinator, hay

Trang 49

 Problem: Ai có trách nhi m qu n lý m t s ệ ả ô ự

ki n h th ng đ u vào (input system event)? ệ ệ ố ầ

 S ki n h th ng đ u vào (input system event) ự ệ ệ ố ầlà 1 s ki n đự ệ ược phát ra b i actor bên ngoài ởChúng k t h p v i các thao tác h th ng ế ợ ơ ệ ố

(system operation) gi ng nh vai trò c a ố ư u

messgase và method

Trang 50

 Ví d : khi thâu ngân s d ng ph n m m POS u ử u ầ ê

nh n nút "End Sale“, anh ta đa phát ra 1 s ki n ấ ự ệ

h th ng ch ra “vi c bán hàng đa k t thúc” ệ ố ỉ ệ ế

Tương t , khi ngự ười dùng ph n m m x lý văn ầ ê ử

b n nh n nút "spell check“, anh ta đa phát ra 1 s ả ấ ự

ki n h th ng ch ra “nhi m v ki m tra chính ệ ệ ố ỉ ệ u ể

t ”.ả

 Controller là 1 đ i tố ượng giao di n không dành ệ

Trang 51

Thao tác h th ng (System operation) ệ ố

 Trong quá trình phân tích, các thao tác h th ng ệ ố

có th đ ể ượ c gán t m cho l p phân tích ạ ơ System

Đi u này không có ngh a là l p ph n m m ê ĩ ơ ầ ê

System phài th c hi n h t các thao tác này Trong ự ệ ế lúc thi t k các l p controller s l n l ế ế ơ ẽ ầ ượ ượ t đ c gán nhi m v th c thi các thao tác h th ng này ệ u ự ệ ố

 Trong ng d ng POS có r t nhi u thao tác h ứ u ấ ê ệ

th ng nh sau: ố ư

◦ endSale()

Trang 52

Case study : h th ng POS ệ ố

 L p nào s là controller cho các s ki n h ơ ẽ ự ệ ệ

th ng ch ng h n nh ố ă ạ ư enterltem và endSale

 Theo m u Controller, có th có 1 s ch n l a ẫ ể ố ọ ựsau khi t o l p thi t k :ạ ơ ế ế

◦ Bi u di n thành 1 h th ng chung đ t tên là ể ễ ệ ố ặ

Register hay POSSystem

◦ Bi u di n thành receiver hay handler ể ễ để qu n lý t t ả ấ

c các s ki n h th ng theo k ch b n c a UC nh ả ự ệ ệ ố ị ả u ư

Trang 53

Case study : h th ng POS ệ ố

Trang 54

L p controller cho enterItem ơ

Trang 57

Bi n pháp tránh Bloated Controllers ê

1. B sung thêm các controllers M t h th ng ổ ô ệ ố

không nên ch có 1 controller Ví d h th ng ỉ u ệ ố

đ t ch vé máy bay, có th ch a các ặ ỗ ể ứ

controller sau:

Trang 58

Bi n pháp tránh Bloated Controllers ê

 Thi t k m t controller chuyên trách làm ế ế ô

nhi m v giao phó vi c hoàn thành t ng thao ệ u ệ ừtác h th ng cho các đ i tệ ố ố ượng khác

Định dạng
Số trang	63
Dung lượng	1,3 MB