Bài giảng Lập trình hướng đối tượng: Nguyên lý thiết kế và mẫu thiết kế - Nguyễn Việt Hà

Nội dung text: Bài giảng Lập trình hướng đối tượng: Nguyên lý thiết kế và mẫu thiết kế - Nguyễn Việt Hà

1. Nguyên lý thiếtkế và mẫuthiếtkế
2. Nội dung „ Thiết kế module „ Chất lượng thiết kế „ Độ đo thiết kế tốt „ Khái niệm về mẫu thiết kế NguyễnViệtHà Nguyên lý thiếtkế 2
3. Tài liệu tham khảo „ Bruce Eckel, Thinking in Patterns „ Erich Gamma, Design Patterns – Elements of Reusable Object-Oriented Software NguyễnViệtHà Nguyên lý thiếtkế 3
4. Thiết kế module Dùa trªn quan ®iÓm "chia ®Ó trÞ" C: ®é phøc t¹p C(p1 + p2) > C(p1) + C(p2) E: nç lùc thùc hiÖn E(p1 + p2) > E(p1) + E(p2) • gi¶m ®é phøc t¹p • côc bé, dÔ söa ®æi • cã kh¶ năng ph¸t triÓn song song • dÔ söa ®æi, dÔ hiÓu nªn dÔ t¸i sö dông NguyễnViệtHà Nguyên lý thiếtkế 4
5. Số lượng module CÇn x¸c ®Þnh sè m«®un tèi −u chi phÝ ph¸t triÓn module gi¸ phÇn mÒm chi phÝ tÝch hîp sè module sè module tèi −u NguyễnViệtHà Nguyên lý thiếtkế 5
6. ChÊt l−îng = Che giÊu th«ng tin „ Sö dông module th«ng qua c¸c giao diÖn tham sè vµ gi¸ trÞ tr¶ l¹i „ Kh«ng cÇn biÕt c¸ch thøc cµi ®Æt thùc tÕ thuËt to¸n cÊu tróc dữ liÖu giao diÖn ngo¹i lai (c¸c m« ®un thø cÊp, thiÕt bÞ vµo/ra) tµi nguyªn hÖ thèng NguyễnViệtHà Nguyên lý thiếtkế 6
7. Che giÊu thông tin: lý do „ Gi¶m hiÖu øng phô khi söa ®æi module „ Gi¶m sù t¸c ®éng cña thiÕt kÕ tæng thÓ lªn thiÕt kÕ côc bé „ NhÊn m¹nh viÖc trao ®æi th«ng tin th«ng qua giao diÖn „ Lo¹i bá viÖc sö dông dữ liÖu dïng chung „ H−íng tíi sù ®ãng gãi chøc năng - thuéc tÝnh cña thiÕt kÕ tèt T¹o ra c¸c s¶n phÈm phÇn mÒm tèt h¬n NguyễnViệtHà Nguyên lý thiếtkế 7
8. ChÊt l−îng thiÕt kÕ „ Phô thuéc bµi to¸n, kh«ng cã ph−¬ng ph¸p tæng qu¸t „ Mét sè ®é ®o Coupling: møc ®é ghÐp nèi giữa c¸c module Cohesion: møc ®é liªn quan lÉn nhau cña c¸c thµnh phÇn bªn trong mét module Understandability: tÝnh hiÓu ®−îc Adaptability: tÝnh thÝch nghi ®−îc NguyễnViệtHà Nguyên lý thiếtkế 8
9. Coupling and Cohesion „ Coupling (ghÐp nèi) ®é ®o sù liªn kÕt (trao ®æi dữ liÖu) giữa c¸c m« ®un ghÐp nèi chÆt chÏ thì khã hiÓu, khã söa ®æi (thiÕt kÕt tåi) „ Cohesion (kÕt dÝnh) ®é ®o sù phô thuéc lÉn nhau cña c¸c thµnh phÇn trong mét module kÕt dÝnh cao thì tÝnh côc bé cao (®éc lËp chøc năng); dÔ hiÓu, dÔ söa ®æi NguyễnViệtHà Nguyên lý thiếtkế 9
10. Coupling normal coupling loose and best „ møc ®é quan hÖ data coupling still very good cña c¸c module stamp coupling ok „ module nªn control coupling ok ghÐp nèi láng lÎo „ cµng láng lÎo cµng dÔ söa ®æi thiÕt kÕ common coupling very bad content coupling tight and worst NguyễnViệtHà Nguyên lý thiếtkế 10
11. GhÐp nèi néi dung (content coupling) • Lµ tr−êng hîp xÊu nhÊt • C¸c module dïng lÉn dữ liÖu cña nhau - c¸c ng«n ngữ bËc thÊp kh«ng cã biÕn côc bé - l¹m dông lÖnh Goto NguyễnViệtHà Nguyên lý thiếtkế 11
12. GhÐp nèi chung (common coupling) • C¸c module trao ®æi dữ liÖu th«ng qua biÕn tæng thÓ • Lçi cña module nµy cã thÓ ¶nh h−ëng ®Õn ho¹t ®éng cña module kh¸c • Khã sö dông l¹i c¸c module m« ®un g©y lçi B A m« ®un gÆp lçi C Dữ liÖu NguyễnViệtHà Nguyên lý thiếtkế 12
13. GhÐp nèi ®iÒu khiÓn (control coupling) • C¸c module trao ®æi th«ng tin ®iÒu khiÓn • Lµm cho thiÕt kÕ khã hiÓu, khã söa ®æi, dÔ nhÇm printRecord (name, sex) printName NguyễnViệtHà Nguyên lý thiếtkế 13
14. GhÐp nèi nh·n (stamp coupling) • C¸c module trao ®æi thõa th«ng tin • Module cã thÓ thùc hiÖn chøc năng ngoµi ý muèn • Lµm gi¶m tÝnh thÝch nghi (age) (personel record) calcAge NguyễnViệtHà Nguyên lý thiếtkế 14
15. GhÐp nèi dữ liÖu (data coupling) • TruyÒn dữ liÖu qua tham sè • NhËn kÕt qu¶ qua tham sè vµ gi¸ trÞ tr¶ l¹i (day of week) (date) calcDayOfWeek NguyễnViệtHà Nguyên lý thiếtkế 15
16. Cohesion „ mçi module functional high and best chØ nªn thùc sequential ok communicational still ok hiÖn mét chøc procedural not bad at all năng temporal still not bad at all logical still not bad at all „ mäi thµnh phÇn nªn tham gia thùc hiÖn chøc năng ®ã coincidental lowest and worst by far NguyễnViệtHà Nguyên lý thiếtkế 16
17. C¸c chñng lo¹i kÕt dÝnh • KÕt dÝnh gom gãp (coincidental cohesion) - c¸c thµnh phÇn kh«ng liªn quan ®Õn nhau • KÕt dÝnh l« gic (logical cohesion) - c¸c thµnh phÇn lµm chøc năng l« gic t−¬ng tù - vd: hµm xö lý lçi chung • KÕt dÝnh thêi ®iÓm (temporal cohesion) - c¸c thµnh phÇn ho¹t ®éng cïng thêi ®iÓm - vd: hµm khëi t¹o (®äc dữ liÖu, cÊp ph¸t bé nhí ) NguyễnViệtHà Nguyên lý thiếtkế 17
18. C¸c chñng lo¹i kÕt dÝnh • KÕt dÝnh thñ tôc (procedural cohesion) - c¸c thµnh phÇn t¹o cã mét thø tù x¸c ®Þnh - vd: tÝnh l−¬ng c¬ b¶n, tÝnh phô cÊp, tÝnh b¶o hiÓm • KÕt dÝnh truyÒn th«ng (communicational cohesion) - c¸c thµnh phÇn truy cËp cïng dữ liÖu - vd: thèng kª (tÝnh max, min, mean, variation ) NguyễnViệtHà Nguyên lý thiếtkế 18
19. C¸c chñng lo¹i kÕt dÝnh • KÕt dÝnh tuÇn tù (sequential cohesion) - output cña mét thµnh phÇn lµ input cña thµnh phÇn tiÕp theo - vd: ¶nh mÇu -> ®en tr¾ng -> ¶nh nÐn • KÕt dÝnh chøc năng (functional cohesion) - c¸c thµnh phÇn cïng gãp phÇn thùc hiÖn mét chøc năng - vd: s¾p xÕp NguyễnViệtHà Nguyên lý thiếtkế 19
20. Understandability TÝnh hiÓu ®−îc „ GhÐp nèi láng lÎo „ KÕt dÝnh cao „ Đ−îc lËp tµi liÖu „ ThuËt to¸n, cÊu tróc dÔ hiÓu NguyễnViệtHà Nguyên lý thiếtkế 20
21. ThiÕt kÕ h−íng ®èi t−îng „ ThiÕt kÕ h−íng ®èi t−îng h−íng tíi chÊt l−îng thiÕt kÕ tèt ®ãng gãi, che dÊu th«ng tin lµ c¸c thùc thÓ ho¹t ®éng ®éc lËp trao ®æi dữ liÖu qua th«ng ®iÖp cã kh¶ năng kÕ thõa côc bé, dÔ hiÓu, dÔ t¸i sö dông NguyễnViệtHà Nguyên lý thiếtkế 21
22. Adaptability TÝnh thÝch nghi ®−îc „ HiÓu ®−îc söa ®æi ®−îc, t¸i sö dông được „ Tù chøa kh«ng sö dông th− viÖn ngoµi m©u thuÉn víi xu h−íng t¸i sö dông NguyễnViệtHà Nguyên lý thiếtkế 22
23. Adaptability (2) „ Các chức năng cần đượcthiếtkế sao cho dễ dàng mở rộng mà không cầnsửacácmãđãcó (Open closed principle) „ Trừutượng hóa là chìa khóa để giải quyết vấn đề này các chứcnăng trừutượng hóa thường bấtbiến các lớpdẫnxuấtcàiđặtcácgiải pháp cụ thể sử dụng đa hình „ Mẫuthiết kế: là thiếtkế chuẩn cho các bài toán thường gặp NguyễnViệtHà Nguyên lý thiếtkế 23
24. Mẫu thiết kế (Design Patterns) „ Creational - Thay thế cho khởi tạo tường minh, ngăn ngừa phụ thuộc môi trường (platform) „ Structural - thao tác với các lớp không thay đổi được, giảm độ ghép nối và cung cấp các giải pháp thay thế kế thừa „ Behavioral - Che dấu cài đặt, che dấu thuật toán, cho phép thay đổi động cấu hình của đối tượng NguyễnViệtHà Nguyên lý thiếtkế 24
25. Abstract Factory „ Một chương trình cần có khả năng chọn một trong một vài họ các lớp đối tượng „ Ví dụ, giao diện đồ họa nên chạy được trên một vài môi trường „ Mỗi môi trường (platform) cung cấp một tập các lớp đồ họa riêng: WinButton, WinScrollBar, WinWindow MotifButton, MotifScrollBar, MotifWindow pmButton, pmScrollBar, pmWindow NguyễnViệtHà Nguyên lý thiếtkế 25
26. Yêu cầu „ Thống nhất thao tác với mọi đối tượng: button, window, Dễ dàng - định nghĩa giao diện (interfaces): „ Thống nhất cách thức tạo đối tượng „ Dễ dàng thay đổi các họ lớp đối tượng „ Dễ dàng thêm họ mới NguyễnViệtHà Nguyên lý thiếtkế 26
27. Giải pháp „ Định nghĩa Factory - lớp để tạo đối tượng: class WidgetFactory { Button makeButton(args) = 0; Window makeWindow(args) = 0; // other widgets } NguyễnViệtHà Nguyên lý thiếtkế 27
28. Giải pháp (tt) „ Định nghĩa Factory chi tiết cho từng họ lớp đối tượng: class WinWidgetFactory extends WidgetFactory { public Button makeButton(args) { return new WinButton(args); } public Window makeWindow(args) { return new WinWindow(args); } } NguyễnViệtHà Nguyên lý thiếtkế 28
29. Giải pháp (tt) „ Chọn họ lớp muốn dùng: WidgetFactory wf = new WinWidgetFactory(); „ Khi khởi tạo đối tượng, không dùng "new"mà gọi: Button b = wf.makeButton(args); „ Thay đổi họ đối tượng - chỉ một lần trong mã cài đặt! „ Thêm họ - thêm một factory, không ảnh hưởng tới mã đang tồn tại! NguyễnViệtHà Nguyên lý thiếtkế 29
30. Sơ đồ lớp NguyễnViệtHà Nguyên lý thiếtkế 30
31. Ứng dụng „ Các hệ điều hành khác nhau „ Các chuẩn look-and-feel khác nhau „ Các giao thức truyền thông khác nhau NguyễnViệtHà Nguyên lý thiếtkế 31
32. Composite „ Một chương trình cần thao tác với các đối tượng dù là đơn giản hay phức tạp một cách thống nhất „ Ví dụ,chương trình vẽ hình chứa đồng thời các đối tượng đơn giản (đoạn thẳng, hình tròn, văn bản) và đối tượng hợp thành (bánh xe = hình tròn + 6 đoạn thẳng). NguyễnViệtHà Nguyên lý thiếtkế 32
33. Yêu cầu „ Thao tác với các đối tượng đơn giản/phức tạp một cách thống nhất - move, erase, rotate, set color „ Một vài đối tượng hợp thành được định nghĩa tĩnh (bánh xe) trong khi một vài đối tượng khác được định nghĩa động (do người dùng lựa chọn ) „ Đối tượng hợp thành có thể tạo ra bằng các đối tượng hợp thành khác „ Chúng ta cần một cấu trúc dữ liệu thông minh NguyễnViệtHà Nguyên lý thiếtkế 33
34. Giải pháp „ Mọi đối tượng đơn giản kế thừa từ một giao diện chung, ví dụ Graphic: class Graphic { abstract void move(int x, int y); abstract void setColor(Color c); abstract void rotate(double angle); } „ Các lớp như Line, Circle kế thừa Graphic và thêm các chi tiết (bán kính, độ dài, ) NguyễnViệtHà Nguyên lý thiếtkế 34
35. Giải pháp (tt) „ Lớp dưới đây cũng là một lớp dẫn xuất: class CompositeGraphic extends Graphic { Graphics list[]; public void rotate(double angle) { for (int i=0; i<list.length; i++) list[i].rotate(); } } NguyễnViệtHà Nguyên lý thiếtkế 35
36. Giải pháp (tt) „ CompositeGraphic là một danh sách nên nó có add(), remove() và count() Graphic nên nó còn có rotate(), move() và setColor() „ Các thao tác đó đối với một đối tượng hợp thành sử dụng một vòng lặp ‘for all’ „ Thao tác thực hiện ngay cả với trường hợp thành phần của Composite lại là một Composite khác - cấu trúc dữ liệu dạng cây „ Có khả năng giữ thứ tự của các thành phần NguyễnViệtHà Nguyên lý thiếtkế 36
37. Giải pháp (tt) „ Ví dụ tạo một đối tượng hợp thành: CompositeGraphic cg; cg = new CompositeGraphic(); cg.add(new Line(0,0,100,100)); cg.add(new Circle(50,50,100)); cg.rotate(90); NguyễnViệtHà Nguyên lý thiếtkế 37
38. Sơ đồ lớp „ Kế thừa đơn „ Lớp cơ sở (root) chứa phương thức add(), remove() NguyễnViệtHà Nguyên lý thiếtkế 38
39. Ứng dụng „ Được dùng trong hầu hết các hệ thống HĐT „ Chương trình soạn thảo „ Giao diện đồ họa „ Cây phân tích cho biên dịch (một khối là một tập các lệnh/lời gọi hàm/các khối khác) NguyễnViệtHà Nguyên lý thiếtkế 39
40. Proxy Pattern „ Các đối tượng có kích thước lớn, chỉ nên nạp vào bộ nhớ khi thực sự cần thiết; hay các đối tượng ở vùng địa chỉ khác (remote objects) „ Ví dụ: Xây dựng một trình soạn thảo văn bản có nhúng các đối tượng Graphic Vấn đề đặt ra: Việc nạp các đối tượng Graphic phức tạp thường rất tốn kém, trong khi văn bản cần được mở nhanh Giải pháp: sử dụng ImageProxy NguyễnViệtHà Nguyên lý thiếtkế 40
41. Sơ đồ lớp NguyễnViệtHà Nguyên lý thiếtkế 41
42. Áp dụng „ Proxy được sử dụng khi nào cần thiết phải có một tham chiếu thông minh đến một đối tượng hơn là chỉ sử dụng một con trỏ đơn giản cung cấp đại diện cho một đối tượng ở một không gian địa chỉ khác (remote proxy). trì hoãn việc tạo ra các đối tượng phức tạp (virtual proxy). quản lý truy cập đến đối tượng có nhiều quyền truy cập khác nhau (protection proxy). smart reference NguyễnViệtHà Nguyên lý thiếtkế 42
43. Strategy „ Chương trình cần chuyển đổi động giữa các thuật toán „ Ví dụ,chương trình soạn thảo sử dụng vài thuật toán hiển thị với các hiệu ứng/lợi ích khác nhau NguyễnViệtHà Nguyên lý thiếtkế 43
44. Yêu cầu „ Thuật toán phức tạp và sẽ không có lợi khi cài đặt chúng trực tiếp trong lớp sử dụng chúng ví dụ: việc cài thuật toán hiển thị vào lớp Document là không thích hợp „ Cần thay đổi động giữa các thuật toán „ Dễ dàng thêm thuật toán mới NguyễnViệtHà Nguyên lý thiếtkế 44
45. Giải pháp „ Định nghĩa lớp trừu tượng để biểu diễn thuật toán: class Renderer { abstract void render(Document d); } „ Mỗi thuật toán là một lớp dẫn xuất FastRenderer, TexRenderer, NguyễnViệtHà Nguyên lý thiếtkế 45
46. Giải pháp (tt) „ Đối tượng "document" tự chọn thuật toán vẽ: class Document { render() { renderer.render(this); } setFastRendering() { renderer = new FastRenderer(); } private Renderer renderer; } NguyễnViệtHà Nguyên lý thiếtkế 46
47. Sơ đồ lớp NguyễnViệtHà Nguyên lý thiếtkế 47
48. Ứng dụng „ Chương trình vẽ/soạn thảo „ Tối ưu biên dịch „ Chọn lựa các thuật toán heuristic khác nhau (trò chơi ) „ Lựa chọn các phương thức quản lý bộ nhớ khác nhau NguyễnViệtHà Nguyên lý thiếtkế 48