Tài liệu công nghệ thông tin - Các nguyên lý cơ bản trong thiết kế HĐT

Chia sẻ: Luong Doan | Ngày: | Loại File: DOC | Số trang:19

Thêm vào BST

Báo xấu

177
lượt xem 40
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

1.Vai trò của thiết kế Thiết kế là 1 công đoạn quan trọng trong qui trình phát triển phần mềm. Thiết kế là bước chuyển tiếp của giai đoạn phân tích và là bước chuẩn bị trước khi chúng ta tiến hành xây dựng phần mềm. Thiết kế là tiến trình mà ở đó xuất hiện mô hình các kiểu mẫu của phần mềm. Các mô hình này chính là những nét phác thảo nên phần mềm. Nó cho chúng ta biết phần mềm chúng ta đang xây dựng là gì, đã có, đang có và sẽ có những gì. Thiết kế là nơi mà ta có...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tài liệu công nghệ thông tin - Các nguyên lý cơ bản trong thiết kế HĐT

Các nguyên lý cơ bản trong thiết kế HĐT Các nguyên lý cơ bản trong thiết kế HĐT (basic object-oriented principles) 1.Vai trò của thiết kế Thiết kế là 1 công đoạn quan trọng trong qui trình phát triển phần mềm. Thiết kế là bước chuyển tiếp của giai đoạn phân tích và là bước chuẩn bị trước khi chúng ta tiến hành xây dựng phần mềm. Thiết kế là tiến trình mà ở đó xuất hiện mô hình các kiểu mẫu của phần mềm. Các mô hình này chính là những nét phác thảo nên phần mềm. Nó cho chúng ta biết phần mềm chúng ta đang xây dựng là gì, đã có, đang có và sẽ có những gì. Thiết kế là nơi mà ta có thể trả lời câu hỏi “Liệu phần mềm này có thể chạy được không?” , “Phần mềm có thể đáp ứng được các yêu cầu của khách hàng hay không?” mà không cần đợi đến công đoạn phát triển. 2.Các nguyên lý thiết kế hướng đối tượng - Nguyên lý ‘đóng mở’: một moudle cần “mở” đối với việc phát triển thêm tính năng nhưng phải “đóng” đối với việc sửa đổi mã nguồn - Nguyên lý thay thế Liskov: Các chức năng của hệ thống vẫn thực hiện đúng đắn nếu ta htay bất kì một lớp đối tượng nào bằng đối tượng kế thừa. - Nguyên lý nghịch đảo phụ thuộc: phụ thuộc vào mức trừu tượng, không phụ thuộc vào mức chi tiết. - Nguyên lý phân tách giao diện: nên có nhiều giao diện đặc thù với bên ngoài hơn là chỉ có một giao diện dùng chung cho một mục đích.
Theo tác giả thì mọi nguyên lý trong lập trình hướng đối tượng đều quy vào một nguyên lý duy nhất là nguyên lý đóng mở (Open-Closed Principle). Do đó đầu tiên sẽ giới thiệu với các bạn về nguyên lý đóng mở. Các nguyên lý sau sẽ làm rõ hơn làm cách nào để đạt được yêu cầu như nguyên lý đóng mở đề ra. Phát biểu nguyên lý Đóng - Mở: “Các thực thể phần mềm (lớp, đơn thể, hàm, …) nên (được xây dựng theo hướng) mở cho việc mở rộng và đóng cho việc sửa đổi”. Nguyên văn tiếng Anh: “SOFTWARE ENTITIES(CLASSES,MODULES,FUNCTIONS,ETC.)SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.” Điểm mấu chốt nhất khi xây dựng phần mềm là “yêu cầu (chức năng) của phần mềm luôn luôn thay đổi”. Sự thay đổi này có thể là khách quan (vd: do nhu cầu công việc cần bổ sung thêm chức năng mới) hoặc chủ quan (vd: chuyên viên lấy yêu cầu hoặc khách hàng không mô tả yêu cầu phần mềm rõ ràng). Như vậy vấn đề đặt ra là làm thế nào viết một phần mềm thay đổi “dễ” chứ không phải là viết một phần mềm mà không hề thay đổi. Nguyên lý đóng mở được đưa ra nhằm phục vụ cho mục đích này. Có hai vế trong nguyên lý này: 1. “Mở cho việc mở rộng”: có nghĩa rằng hoạt động của thực thể phần mềm (lớp, đơn thể, hàm,…) có thể được mở rộng. Chúng ta có thể tạo ra thực thể hoạt động theo những cách mới và khác hẳn khi yêu cầu của ứng dụng thay đổi hoặc để thỏa mãn nhu cầu của ứng dụng mới. 2. “Đóng cho việc sửa đổi”: có nghĩa rằng đoạn mã (code) của thực thể này không bị xâm phạm. Không ai được phép thay đổi đoạn mã của thực thể. Có vẻ như hai vế này mâu thuẫn lẫn nhau. Bởi vì khi chúng ta muốn thêm hoặc sửa đổi yêu cầu thì có vẻ “chắc chắn” chúng ta phải sửa đổi đoạn mã cũ. Để làm rõ hơn hai vế trên, chúng ta xét ví dụ chương trình Draw. Chương trình Draw là một chương trình tương tự như Paint trong Windows. Nó cho phép chúng ta vẽ các đối tượng hình học ra màn hình. Bỏ qua các vấn đề liên quan đến giao diện người dùng, chúng ta chỉ tập trung đến thao tác vẽ (draw) của các đối tượng. Giả sử yêu cầu ban đầu của chương trình Draw là chỉ thao tác trên hai loại đối tượng là hình tròn và hình vuông. Sử dụng phương pháp lập trình cấu trúc (structured programming) (hay còn gọi phương pháp lập trình hướng thủ tục – procedural programming), chương trình phác thảo sơ lược sẽ có dạng như sau (sử dụng ngôn ngữ C++): PHP Code: enum ShapeType {circle, square}; struct Shape
{ ShapeType itsType; }; struct Circle { ShapeType itsType; double itsRadius; Point itsCenter; }; struct Square { ShapeType itsType; double itsSide; Point itsTopLeft; }; // không cần quan tâm chi tiết đến cài đặt hai hàm này void DrawSquare(struct Square*); void DrawCircle(struct Circle*); typedef struct Shape *ShapePointer; void DrawAllShapes(ShapePointer list[], int n) { int i; for (i=0; iitsType) { case square: DrawSquare((struct Square*)s); break; case circle: DrawCircle((struct Circle*)s); break; } } } Đoạn mã ở trên có thể dễ dàng đọc hiểu. Trong đó hàm DrawAllShapes có nhiệm vụ vẽ các đối tượng hình học (hình tròn, hình vuông) ra màn hình. Tham số của hàm DrawAllShapes là một mảng các con trỏ chứa địa chỉ của các đối tượng hình học cần được vẽ. Để đạt được điều đó, hàm DrawAllShapes đến phiên nó lại cần sự trợ giúp của hai hàm vẽ cụ thể cho hai loại đối tượng hình học là hàm DrawCircle và DrawSquare. Để gọi được hai hàm này, hàm DrawAllShapes cần phải xác định đối tượng hiện tại đang thao tác là đối tượng nào thông qua biến thành viên itsType của từng đối tượng. Có vẻ chương trình Draw đã được hoàn thành và đúng với yêu cầu đề ra. Vấn đề sẽ xuất hiện khi chúng ta muốn vẽ thêm một đối tượng khác, như hình tam giác chẳng hạn. Lúc này, hàm DrawAllShapes cần phải xử lý thêm một trường hợp nữa là hình tam giác. Đoạn mã thêm vào và sửa đối sẽ như sau: PHP Code:
enum ShapeType {circle, square, triangle};//kiểu dữ liệu liệu kê struct Triangle { ShapeType itsType; Point itsVertices[3]; }; // không cần quan tâm chi tiết đến cài đặt hàm này void DrawTriangle(struct Triangle*); void DrawAllShapes(ShapePointer list[], int n) { int i; for (i=0; iitsType) { case square: DrawSquare((struct Square*)s); break; case circle: DrawCircle((struct Circle*)s); break; // thêm vào case triangle: DrawTriangle((struct Triangle*)s); break; } } } Để ý trong trường hợp này, khi một yêu cầu mới phát sinh (vẽ hình tam giác), thì đoạn mã của hàm DrawAllShapes đã bị thay đổi. Bản thiết kế chương trình Draw của chúng ta đã vi phạm nguyên lý đóng mở. Vậy bản thiết kế chương trình Draw nên như thế nào? Hai kỹ thuật chính để đạt được nguyên lý Đóng - Mở là sự trừu tượng (abstraction) và tính đa hình (đa xạ : polymorphism). Các bạn có thể tự tìm hiểu hai kỹ thuật trừu tượng hóa và đa hình, vốn là hai kỹ thuật mà bất cứ một ngôn ngữ lập trình hướng đối tượng, bao gồm C+ +, phải hỗ trợ. Tôi không trình bày chi tiết hai kỹ thuật trên mà chỉ trình bày sơ lược theo ví dụ thiết kế Draw mà chúng ta đang hướng đến. Chương trình Draw ở trên có thể mô hình như sau:
Nghĩa là hàm DrawAllShapes sử dụng trực tiếp (được thể hiện bằng đoạn thẳng có dấu mũi tên mảnh) hai đối tượng (hai lớp) Circle và Square, tương ứng là hình tròn và hình vuông. Chúng ta sẽ trừu tượng hóa quan hệ này bằng cách tạo ra một đối tượng gọi là hình (Shape). Một cách cảm tính chúng ta có thể thấy một đối tượng hình tròn hoặc hình vuông hoặc hình tam giác đều là một đối tượng hình. Hàm DrawAllShapes thay vì thao tác trực tiếp trên các đối tượng hình tròn và hình vuông sẽ thao tác trên các đối tượng hình chung chung mà chúng ta đã trừu tượng hóa. Mô hình chương trình Draw sẽ trở thành như sau: Các lớp Circle, Square sẽ được kế thừa (được thể hiện bằng đoạn thẳng có dấu mũi tên đậm) từ lớp Shape. Đoạn mã chương trình Draw cho mô hình thiết kế mới sẽ như sau: PHP Code: class Shape { public: // hàm thuần ảo (pure virtual) virtual void Draw() const=0; }; class Square : public Shape { protected: double itsSide; Point itsTopLeft; public:
// không cần quan tâm chi tiết cài đặt hàm này virtual void Draw() const; }; class Circle : public Shape { protected: double itsRadius; Point itsCenter; public: // không cần quan tâm chi tiết cài đặt hàm này virtual void Draw() const; }; void DrawAllShape(set& list) { for(iterator i(list); i; i++) (*i) ->Draw(); }; Qua đoạn mã chương trình Draw mới, có thể thấy hàm DrawAllShapes không quan tâm chi tiết đến từng đối tượng hình cụ thể như là hình tròn hay hình vuông (không có câu lệnh if), mà nó chỉ quan tâm đến sự trừu tượng của các đối tượng hình này – Shape. Nhờ cơ chế đa hình (đa xạ) mà hàm Draw của lớp Shape sẽ được liên kết với hàm Draw của lớp Circle hoặc Square tùy thuộc vào đối tượng hiện tại thuộc lớp Circle hay Square. Trong đoạn chương trình trên cũng xuất hiện một khái niệm mà các bạn ít quen thuộc là iterator và set, các bạn có thể tự tìm hiểu thêm trong thư viện STL đi kèm với C++. Quay trở lại với chương trình Draw của chúng ta, nếu muốn chương trình vẽ thêm đối tượng tam giác thì chúng ta chỉ việc thêm vào lớp Triangle, được dẫn xuất (thừa kế) từ lớp Shape. PHP Code: class Shape { public: // hàm thuần ảo (pure virtual) virtual void Draw() const=0; }; class Square : public Shape { protected: double itsSide; Point itsTopLeft; public: // không cần quan tâm chi tiết cài đặt hàm này
virtual void Draw() const; }; class Circle : public Shape { protected: double itsRadius; Point itsCenter; public: // không cần quan tâm chi tiết cài đặt hàm này virtual void Draw() const; }; class Triangle : public Shape { protected: Point vertices[3]; public: // không cần quan tâm chi tiết cài đặt hàm này virtual void Draw() const; }; void DrawAllShape(set& list) { for(iterator i(list); i; i++) (*i) ->Draw(); }; Có thể thấy, chúng ta chỉ cần thêm mới vào lớp Triangle, hàm DrawAllShapes, cũng như tất cả các thành phần đoạn mã đã có của chương trình Draw, không hề thay đổi. Bản thiết kế mới của chương trình Draw thỏa mãn nguyên lý Đóng – Mở. Open-closed là nguyên li trung tâm, rất quan trọng trong thiết kế hướng đối tượng vì chính nguyên lí này làm cho lập trình hướng đối tượng có tính tái sử dụng (reusability) và dễ bảo trì (maintainability). Tham khảo thêm ở đây và ở đây. Như đã đề cập ở trên hai kỹ thuật quan trọng để đạt được nguyên lý đóng mở là trừu tượng hóa và tính đa hình. Trong C++, tính đa hình được thể hiện thông qua sự thừa kế (inheritance). Vậy khi nào thì một lớp A nào đó nên được thừa kế từ lớp B đã có? Nguyên lý thay thế Liskov Nếu xem nguyên lý Mở - Đóng là nguyên lý cơ sở quan trọng nhất của lập trình và thiết kết theo hướng đối tượng, thì nguyên lý Thay thế Liskov là một phương tiện để chúng ta kiểm tra xem chương trình hoặc bản thiết kế của chúng ta có thoả nguyên lý Mở - Đóng hay không. Nếu nguyên lí này bị vi phạm, function có sử dụng reference hay pointer tới object của lớp cha phải kiểm tra kiểu của object để đảm bảo chương trình có thể chạy đúng, và việc này vi phạm nguyên lí open-closed nhắc đến ở trên. Tham khảo thêm ở đây và ở đây. Trước khi đi vào nguyên lý chúng ta xét một chương trình ví dụ, cũng liên quan đến các đối tượng hình vẽ như chúng ta đã đề cập trong chương trình Draw, nhưng được giản lược đi
nhiều chỉ để đủ cho việc minh họa nguyên lý Thay thế Liskov. Cụ thể chúng ta xét lớp Rectangle mô tả đối tượng hình chữ nhật và một hàm f thao tác trên đối tượng lớp Rectangle. PHP Code: class Rectangle { public: void SetWidth(double w) {itsWidth=w;} void SetHeight(double h) {itsHeight=w;} double GetHeight() const {return itsHeight;} double GetWidth() const {return itsWidth;} private: double itsWidth; double itsHeight; }; // hàm thao tác trên đối tượng Rectangle& void f(Rectangle& r) { r.SetWidth(32); } Đoạn mã đã giải thích rõ ràng công dụng của lớp Rectangle, cũng như của hàm f. Phát biểu nguyên lý: Các hàm mà sử dụng con trỏ hoặc tham chiếu đến các (đối tượng) lớp cơ sở cũng phải có thể sử dụng các đối tượng của các lớp dẫn xuất mà không cần biết chúng. Nguyên văn tiếng Anh: FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT. Để hiểu nguyên lý này chúng ta thử xét những ví dụ vi phạm. Giả sử chương trình Draw mở rộng thao tác trên những đối tượng hình vuông, lớp Square. Theo bạn, chúng ta nên tạo mới lớp hình vuông hay kế thừa từ lớp Rectangle. Để trả lời câu hỏi này thì theo như phần lớn các bạn đã được học, các bạn cần trả lời câu hỏi là “Một đối tượng hình vuông có phải là một (IS A) đối tượng hình chữ nhật hay không?” Nếu câu trả lời là có, thì lớp hình vuông là lớp kế thừa từ lớp hình chữ nhật và ngược lại. Trong trường hợp này, dĩ nhiên câu trả lời là có. Vậy chúng ta sẽ cho lớp hình vuông kế thừa từ lớp hình chữ nhật và xem điều gì sẽ xảy ra. Đoạn mã của lớp Square có dạng như sau: PHP Code: class Square: public Rectangle { public: void Square::SetWidth(double w) { Rectangle::SetWidth(w); Rectangle::SetHeight(w); } void Square::SetHeight(double h) { Rectangle::SetHeight(h);
Rectangle::SetWidth(h); } }; Lớp Square được kế thừa từ lớp Rectangle, và do đặc điểm của hình vuông là hai cạnh bằng nhau, nên khi đặt chiều rộng thì chúng ta cũng phải đặt chiều dài và ngược lại. Bỏ qua lý do tốn bộ nhớ (do phải lưu cả chiều dài và chiều rộng), chúng ta xét về logic thực hiện chương trình. Chúng ta thử tạo ra hai đối tượng hình vuông và hình chữ nhật và gọi hàm f thao tác trên hai đối tượng này theo hàm main như sau: PHP Code: int main() { Rectangle r; Square s; f(r); // thực hiện đúng f(s); // thực hiện sai vì hàm SetWidth là hàm của hình chữ nhật … return 0; } Nếu chúng ta truyền vào một đối tượng Rectangle (r) thì hàm f thực hiện đúng như mong đợi. Nhưng nếu chúng ta truyền vào một đối tượng Square (s) thì hàm f thực hiện sai vì câu lệnh r.SetWidth(32) sẽ gọi hàm SetWidth của lớp Rectangle và do đó gây ra vi phạm ràng buộc là chiều dài và chiều rộng của đối tượng s phải bằng nhau. Trong trường hợp này, hàm f đã vi phạm nguyên lý Thay thế Liskov. Nó họat động tốt trên đối tượng truyền vào thuộc lớp cơ sở (lớp Rectanlge) nhưng không họat động tốt trên đối tượng truyền vào thuộc lớp dẫn xuất (lớp Square). Giải pháp khắc phục rất đơn giản chúng ta sẽ thay đổi hai hàm thuộc lớp Rectangle thành hàm ảo (virtual function) và sử dụng cơ chế đa xạ. Để ý rằng, khi chương trình Draw vi phạm nguyên lý Thay thế Liskov thì nó cũng vi phạm nguyên lý Mở - Đóng (vì phải chỉnh sửa đoạn mã các thực thể đã có). PHP Code: class Rectangle{ public: // đổi thành hàm ảo (virtual) virtual void SetWidth(double w) {itsWidth=w;} // đổi thành hàm ảo (virtual) virtual void SetHeight(double h) {itsHeight=h;} double GetHeight() const {return itsHeight;} double GetWidth() const {return itsWidth;} private: double itsHeight; double itsWidth; }; class Square: public Rectangle {
public: void Square::SetWidth(double w) { Rectangle::SetWidth(w); Rectangle::SetHeight(w); } void Square::SetHeight(double h) { Rectangle::SetHeight(h); Rectangle::SetWidth(h); } }; Vấn đề đã được giải quyết xong, hàm f bây giờ có thể hoạt động tốt cho cả đối tượng truyền vào thuộc lớp Rectangle lẫn đối tượng truyền vào thuộc lớp Square. Chương trình bây giờ thỏa mãn nguyên lý Thay thế Liskov. Để minh họa tiếp tục, chúng ta xét hàm g như sau. Hàm g có vai trò như một hàm test bảo đảm rằng thao tác thực hiện hai hàm SetWidth và SetHeight của lớp Rectangle phải hoàn toàn đúng đắn. PHP Code: void g(Rectangle& r) { r.SetWidth(5); r.SetHeight(4); assert(r.GetWidth()*r.GetHeight())==20); } Dễ thấy rằng, hàm g hoạt động tốt nếu chúng ta truyền vào một đối tượng Rectangle (r), assert thành công, nhưng sẽ không hoạt động tốt nếu chúng ta truyền vào một đối tượng Square (s), assert không thành công. (Các bạn tham khảo thêm hàm assert, nó được dùng chủ yếu cho mục đích debug và test chương trình). Trong trường hợp này, chúng ta kết luận chương trình không thỏa mãn nguyên lý Thay thế Liskov. Vì hàm g hoạt động tốt trên các đối tượng lớp cơ sở (Rectangle) nhưng không hoạt động tốt trên các đối tượng lớp dẫn xuất (Square). Vậy nguyên nhân là do đâu? Lý do chính ở đây, là lớp Square không nên kế thừa từ lớp Rectangle. Và việc trả lời cho câu hỏi: “Đối tượng hình vuông có phải là một đối tượng hình chữ nhật hay không?” cho đáp án là “có” chỉ là điều kiện cần cho việc quyết định lớp Square (hình vuông) có nên kế thừa từ lớp Rectangle (hình chữ nhật) hay không. Điều kiện đủ cần phải xét là nó có thỏa nguyên lý Liskov hay không. Lưu ý rằng việc bảo đảm nguyên lý Thay thế Liskov cho mọi hàm, mọi thực thể trong phần mềm là rất khó. Tuy nhiên việc cố gắng thực hiện đúng theo nguyên lý Thay thế Liskov sẽ giúp ích cho việc mở rộng và bảo trì phần mềm. Bởi vì nếu vi phạm nguyên lý Thay thế Liskov thì tất yếu sẽ vi phạm nguyên lý Mở Đóng (cụ thể là tính Đóng).
Nguyên l ý đảo phụ t huộc ( Dependency I nver si on Pr i nci pl e) Phát bi ểu nguyên lý : A. Các đơn thể cấp cao không nên phụ thuộc vào các đơn thể cấp thấp. Cả hai nên phụ thuộc vào những cái tr ừu t ượng. B. Cái tr ừu t ượng không nên phụ thuộc vào cái chi ti ết. Cái chi ti ết nên phụ thuộc vào cái tr ừu t ượng. Nguyên văn ti ếng Anh: A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOWLEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS. B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS. Thực hi ện m t bằng cách dùng abstract layer như h ình dưới . ộ Tham khảo thêm ở chỗ này, chỗ này và chỗ này.
Để l àm rõ nguyên lý Đảo Phụ thuộc chúng ta xét m t ví dụ đơn gi ản sau: ộ g i ả sử chúng ta cần vi ết m t chương tr ình nhằm đọc các ký t ự được nhập ộ t ừ bàn phím sau đó xuất ra máy in. D dàng thấy r ằng, chương tr ình của ễ chúng ta cần ba chức năng t ương ứng với ba hàm: ReadKeyboard để đọc m t ộ ký t ự t ừ bàn phím; WritePrinter để xuất ký t ự ra máy in; và hàm Copy để kết hợp hai hàm trên l ại được chức năng như chương tr ình mong mu n.ố Thi ết kế và đoạn mã chương tr ình như sau: PHP Code: // không quan tâm chi tiết cài đặt hai hàm này int ReadKeyboard(); void WritePrinter(int c); void Copy() { int c; while (c = ReadKeyboard()) != EOF) WritePrinter(c); } Đoạn mã chương trình ngắn gọn và dễ dàng đọc hiểu. Lưu ý rằng chúng ta bỏ qua chi tiết cài đặt của hai hàm ReadKeyboard và WritePrinter. Có vẻ chương trình đã được hoàn thành một cách tốt đẹp. Phương pháp mà chúng ta đang áp dụng để thiết kế ra chương trình này gọi là phương pháp top-down, thường được áp dụng trong lập trình cấu trúc (structured programming) – hay còn gọi là lập trình hướng thủ tục (procedural programming). Các bạn có thể tự tìm hiểu phương pháp thiết kế top-down. Chúng ta sẽ không đi chi tiết về nó. Chỉ nhắc lại ý tưởng chính của nó là chia để trị, chia chức năng cần hoàn thành thành các chức năng nhỏ hơn và tiếp tục cho đến khi nó đủ nhỏ để có thể dễ lập trình và dễ kiểm soát. Để ý hơn nữa, các bạn có thể thấy hàm copy sử dụng hai hàm ReadKeyboard và WritePrinter. Chúng ta nói hàm Copy ở cấp cao, còn hai hàm ReadKeyboard và WritePrinter ở cấp thấp. Giả sử yêu cầu của chương trình được thay đổi, chương trình được yêu cầu đọc ký tự từ bàn phím và xuất ra hoặc máy in hoặc đĩa cứng (tập tin). Đoạn mã được thay đổi như sau để phù hợp với yêu cầu của chương trình. PHP Code: // không quan tâm chi tiết cài đặt ba hàm này int ReadKeyboard();
void WritePrinter(int c); void WriteDisk(int c); // hàm copy có thay đổi enum outputDevice {printer, disk}; void Copy(outputDevice dev) { int c; while (c = ReadKeyboard()) != EOF) if (dev == printer) WritePrinter(c); else WriteDisk(c); } Ở đây xuất hiện một vấn đề chức năng hàm Copy phải được thay đổi để phù hợp với yêu cầu mới. Lý do hàm Copy, hàm cấp cao, đã bị phụ thuộc vào các hàm ReadKeyboard, WritePrinter, và WriteDisk, vốn là các hàm cấp thấp. Thiết kế chương trình của chúng ta đã bị vi phạm nguyên lý Đảo Phụ thuộc (xem vế A của nguyên lý). Để sửa chữa chúng ta phải để các hàm cấp cao không phụ thuộc vào các hàm cấp thấp, mà phải để cả các hàm cấp cao (Copy) và các hàm cấp thấp (ReadKeyboard, WritePrinter, và WriteDisk) phụ thuộc vào những cái trừu tượng. Thiết kế chương trình và đoạn mã chương trình được sửa đổi như sau: PHP Code: class Reader { public: virtual int Read() = 0; }; class KeyboardReader: public Reader { public: // không quan tâm đến chi tiết cài đặt virtual int Read(); }; class Writer { public: virtual void Write(char) = 0; }; class PrinterWriter: public Writer { public:
// không quan tâm đến chi tiết cài đặt virtual void Write(char); }; void Copy(Reader& r, Writer& w) { int c; while((c=r.Read()) != EOF) w.Write(c); } Để ý với bản thiết kế mới của chương trình, đơn thể cấp cao (hàm Copy) không phụ thuộc và các đơn thể cấp thấp (lớp KeyboardReader, PrinterWriter). Tất cả chúng phụ thuộc và những cái trừu tượng (lớp trừu tượng Reader và Writer). Hàm main() của chương trình chính nếu có sẽ có dạng như sau: PHP Code: int main() { KeyboardReader keyboard; PrinterWriter printer; Copy(keyboard, printer); return 0; } Giả sử chương trình yêu cầu thay vì xuất ra máy in thì xuất ra đĩa cứng (tập tin). Bản thiết kế và đoạn mã chương trình sẽ thêm vào lớp DiskWriter, dẫn xuất từ lớp Writer. Hàm Copy và các lớp khác không hề thay đổi. Nguyên lý Đóng – Mở đã được bảo đảm. Hoặc thay vì đọc từ bàn phím thì đọc từ các thiết bị khác như đĩa thì sự thay đổi đơn thuần chỉ là sự thêm vào các lớp cấp thấp mới. Bản thiết kế này cũng giải thích vế B trong phát biểu nguyên lý: “Cái trừu tượng không phụ thuộc vào cái chi tiết. Cái chi tiết phải phụ thuộc vào cái trừu tượng.” Rõ ràng, khi lớp trừu tượng Reader thay đổi thì các lớp dẫn xuất (lớp con) từ nó phải thay đổi nhưng chiều ngược lại thì không. Tóm lại nếu như nguyên lý Đóng – Mở đưa ra mục tiêu thì nguyên lý thay thế Liskov là một phương tiện để kiểm tra mục tiêu đó có đạt được hay không và nguyên lý Đảo Phụ thuộc là một phương tiện để đạt được mục tiêu đó.
Nguyên lý chia tách giao diện (Interface Segregation Principle) Trong 3 nguyên lý trước, kỹ thuật trừu tượng hóa với sự xuất hiện của khái niệm lớp trừu tượng đã xuất hiện rất nhiều và giúp cho chương trình thỏa mãn nguyên lý Mở - Đóng. Nguyên lý chia tách giao diện (Interface Segragation Principle) sẽ đóng vai trò định hướng trong việc thiết kế các lớp trừu tượng này. Phát biểu nguyên lý: Không nên buộc các thực thể (phần mềm) khách phụ thuộc vào các giao diện mà chúng không hề sử dụng. Nguyên văn tiếng Anh: CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE. Khi một client bị ép phải phụ thuộc vào những interface mà nó không sử dụng thì nó sẽ bị lệ thuộc vào những thay đổi của interface đó. Chúng ta cần phải tránh điều này nhiều nhất có thể bằng cách chia nhỏ interface. Tham khảo thêm ở đây. Trước hết chúng ta đi làm sáng tỏ một khái niệm mới xuất hiện là giao diện (interface). Xét lại ví dụ chương trình vẽ hình Draw ở nguyên lý Mở - Đóng mà chúng ta đã dùng. Để cho dễ minh họa khái niệm giao diện, tôi sẽ thêm vào một chức năng trong chương trình Draw ngoài chức năng vẽ hình là chức năng tịnh tiến một hình theo một vector cho trước. Đây là hai chức năng cơ bản trong các chương trình đồ họa vector. Đồng thời chúng ta sẽ thêm vào một đối tượng hình học được thao tác nữa là đối tượng đoạn thẳng (Line). Lớp Line sẽ được thừa kế từ lớp Shape chúng ta đã có. Thiết kế chương trình và mã nguồn các lớp sẽ có dạng như sau: PHP Code: class Shape { public: // hàm thuần ảo (pure virtual)
virtual void Draw() const=0; virtual void Transfer(double dx, double dy) = 0; }; class Square : public Shape { protected: double itsSide; Point itsTopLeft; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); }; class Circle : public Shape { protected: double itsRadius; Point itsCenter; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); }; class Line : public Shape { protected: Point itsStartPoint, itsEndPoint; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); }; Câu hỏi đặt ra rất đơn giản: ý nghĩa của “lớp” Shape – “lớp” Hình là gì? Chúng ta vẫn gọi nó là lớp trừu tượng. Thật sự đó là một cách nói khỏa lấp. Lớp và đối tượng là hai khái niệm đi kèm nhau và liên quan chặt chẽ với nhau. Lớp dùng để tạo ra đối tượng, ngược lại nếu không phải vậy nó không phải là lớp. Shape không phải là một lớp, bởi nó không có khả năng tạo ra các đối tượng. Shape được gọi là một giao diện (interface). Một cách nôm na: giao diện là tập hợp các thành phần (thường là hàm) của một đối tượng mà các đối tượng khác có thể thấy. Một công thức mà các bạn thường hay gặp trong các bài giảng về lớp (đối tượng) là: Đối tượng = các hàm + các biến hay đối tượng = các phương thức + các dữ liệu. Những “các hàm” hay “các phương thức” ở đây chính là giao diện của đối tượng. Rất tiếc trong C++ (không như các ngôn ngữ hiện đại hơn như Java hay .NET) không có khái niệm giao diện một cách trực tiếp, mà nó được biểu diễn thông qua khái niệm lớp, gọi là lớp trừu tượng. Do đó khi chúng ta tạo ra một lớp trừu tượng thì chúng ta sẽ gọi nó là tạo ra một giao diện. Trong ví dụ trên chúng ta có giao diện Shape gồm 2 chức năng: Draw - vẽ và Transfer - tịnh tiến. Lớp Circle, Square và Line được gọi là sử dụng (hay thực hiện) giao diện Shape. Lưu ý rằng khái niệm giao diện = lớp trừu tượng được sử dụng rộng rãi trong các ngôn ngữ lập trình như Java hay .NET. Để minh họa sự vi phạm và hậu quả của sự vi phạm nguyên lý Chia tách Giao diện, chúng ta
hãy thêm vào chương trình Draw chức năng tô màu – Fill. Một cách đơn giản và có tính minh họa, chúng ta sẽ đưa hàm Fill vào trong giao diện Shape. PHP Code: enum ColorType {red, green, blue}; enum PatternType {solid, vertical, horizontal}; class Shape { public: // hàm thuần ảo (pure virtual) virtual void Draw() const=0; virtual void Transfer(double dx, double dy) = 0; virtual void Fill(ColorType color, PatternType pattern) = 0; }; class Square : public Shape { protected: double itsSide; Point itsTopLeft; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); virtual void Fill(ColorType color, PatternType pattern); }; class Circle : public Shape { protected: double itsRadius; Point itsCenter; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); virtual void Fill(ColorType color, PatternType pattern); }; class Line : public Shape { protected: Point itsStartPoint, itsEndPoint; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); // cài đặt hàm Fill như thế nào virtual void Fill(ColorType color, PatternType pattern); }; Hàm Fill có hai tham số chỉ ra màu dùng để tô và mẫu dùng để tô (đặc, dọc, ngang,….). Hai kiểu ColorType và PatternType chỉ có tính minh họa. Một cách tự nhiên, các lớp sử dụng giao diện Shape sẽ phải thực hiện (implement) hay định nghĩa các chức năng được mô tả trong giao diện Shape, trong đó có chức năng Fill. Với hai lớp Circle và Square, điều này là rõ ràng và có ý nghĩa. Nhưng đối với Line thì chức năng Fill sẽ làm gì? Ở đây xuất hiện một hiện tượng mà chúng ta gọi là “giao diện bị ô nhiễm” (polluted
interface). Chúng ta đã bắt buộc lớp Line phải định nghĩa (hay phụ thuộc) vào hàm Fill mà nó không hề muốn sử dụng. Nguyên lý Chia tách Giao diện đã bị vi phạm. Vậy thiết kế phần mềm nên được thay đổi như thế nào? Chúng ta sẽ chia tách giao diện Shape thành các giao diện khác và bảo đảm không có lớp nào bắt buộc phải sử dụng các giao diện mà chúng không mong muốn. Giao diện Shape được tách ra thành hai giao diện: giao diện Shape mới, dành cho các các đối tượng hình vẽ không tô được, chứa hàm Draw và Transfer và FilledShape chứa hàm Fill kế thừa từ giao diện Shape, dành cho các đối tượng hình vẽ có tô được và. (Lẽ ra nên có 3 giao diện UnfilledShape thì có lý hơn. Tuy nhiên với ví dụ này chỉ cần chia tách giao diện Shape thành 2 giao diện mới là đủ.) Lớp Circle và Square sẽ thực hiện giao diện FilledShape và lớp Line sẽ thực hiện giao diện Shape. Thiết kế và mã nguồn chương trình được chỉnh lại như sau: PHP Code: enum ColorType {red, green, blue}; enum PatternType {solid, vertical, horizontal}; class Shape { public: // hàm thuần ảo (pure virtual) virtual void Draw() const=0; virtual void Transfer(double dx, double dy) = 0; }; class FilledShape : public Shape { public: // hàm thuần ảo (pure virtual) virtual void Fill(ColorType color, PatternType pattern) = 0; }; class Square : public FilledShape { protected: double itsSide; Point itsTopLeft; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); virtual void Fill(ColorType color, PatternType pattern); }; class Circle : public FilledShape {
protected: double itsRadius; Point itsCenter; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); virtual void Fill(ColorType color, PatternType pattern); }; class Line : public Shape { protected: Point itsStartPoint, itsEndPoint; public: // không cần quan tâm chi tiết cài đặt các hàm này virtual void Draw() const; virtual void Transfer(double dx, double dy); }; Đoạn mã chương trình thể hiện những điều đã nói ở trên nên không cần phải giải thích. Bản thiết kế này thỏa nguyên lý Chia tách Giao diện. Các bạn có thể đặt câu hỏi nếu vi phạm nguyên lý Chia tách Giao diện thì sẽ gây ra hậu quả gì ảnh hưởng đến phần mềm? Có hai hậu quả chính: 1) xét giao diện Shape như cũ (tức có 3 chức năng: Draw, Transfer và Fill) bị ô nhiễm thì dễ dàng thấy rằng mọi giao diện dẫn xuất (tức kế thừa) từ giao diện Shape sẽ bị ô nhiễm, và cứ tích lũy như vậy trong cây phân cấp kế thừa giao diện. Hiện tượng này gọi là fat interface – giao diện phì. 2) Nếu chấp nhận việc giao diện Shape bị ô nhiễm, thì lúc đó trong lớp Line, chúng ta cài đặt hàm Fill và một giải pháp đặt ra là cài đặt rỗng, tức thân hàm không làm gì cả. Hoặc một giải pháp khác là ngay ở giao diện Shape, hàm Fill không phải là hàm thuần ảo mà là hàm rỗng (nil function). Với cả hai giải pháp này, các bạn dễ dàng thấy rằng nó sẽ có nguy cơ rất cao gây ra vi phạm nguyên lý Thay thế Liskov. Để cho đơn giản các bạn có thể lấy ví dụ các lớp như trên nhưng xét hai hàm dễ tưởng tượng hơn là tính chu vi và tính diện tích, rồi viết một hàm tính tổng diện tích hoặc tính chu vi. Lúc đó hàm tính tổng diện tích (hoặc chu vi) sẽ vi phạm nguyên lý Thay thế Liskov. Tóm lại nguyên lý Chia tách Giao diện giúp chúng ta có định hướng tốt về việc thiết kế các lớp trừu tượng hay còn gọi là giao diện. Qua những ví dụ trên, các bạn sẽ thấy, lập trình hướng đối tượng thật sự liên quan đến công việc thiết kế rất nhiều. Nó không chỉ là công việc lập trình, coding. Ngoài 4 nguyên lý về thiết kế và lập trình hướng đối tượng mà tôi đã chia sẻ cùng các bạn, các bạn có thể tìm hiểu thêm các nguyên lý khác trong trang web objectmentor. Tuy nhiên với 4 nguyên lý này các bạn có thể lý giải và dễ hiểu hơn các mẫu phát triển phần mềm – software pattern. 1.