SOLID - Bài 3: Liskov's Substitution Principle (LSP)

List các bài đã viết:
Nguyên tắc cơ bản trong thiết kế OOP: Bài mở đầu Generalization và Specification
SOLID - Bài 1: Single Responsibility Principle (SRP)
SOLID - Bài 2: Open Closed Principle (OCP)
SOLID - Bài 3: Liskov's Substitution Principle (LSP)
SOLID - Bài 4: Interface Segregation Principle (ISP)
SOLID - Bài 5: Dependency Inversion Principle (DIP)

Ta tiếp tục nguyên tắc thứ 3, ứng với chữ cái thứ 3 của SOLID - Liskov's Substitution Principle(LSP). Tôi tạm dịch là "Nguyên Tắc Đại Diện Cha-Con Liskov", nghe hơi kỳ dị và lệch nghĩa, nhưng vì tôi nhận thấy các bạn của tôi luôn gặp vấn đề về ghi nhớ nguyên tắc này nếu để nguyên mẫu. Vì thế tôi đã phải ngồi suy nghĩ cả nửa ngày để nghĩ ra một cái tên sao cho hình tượng nhất. Điều nữa là, tôi vẫn để lại chữ Liskov vì muốn giữ lại bản quyền tác giả, người đã đưa ra nó.
Bây giờ bạn sẽ tìm hiểu tại sao cái tên tôi đặt lại matched với nguyên tắc này. Nguyên văn của nguyên tắc này phát biểu như sau:
"Lớp con phải luôn có thể thay thế hoàn toàn bằng lớp cha của nó."
Có thể là tôi hiểu không tới, nhưng thành thực mà nói tôi không ưng ý với phát biểu này mấy. Vì vậy, tôi xin phép dịch lại theo ý mình cho dễ hiểu và dễ nhớ như sau, dĩ nhiên bạn có quyền thích kiểu nào cũng được miễn bạn cảm thấy thoải mái và không hiểu sai lệch là được:
"Lớp con khi đại diện cho lớp cha không được thay thế hành vi của của lớp cha"
Đây có thể hiểu một cách nôm na thế này: Những đứa con được quyền tự quyết định hành vi của nó miễn là không ảnh hưởng với truyền thống gia đình. Mỗi khi quyết định tạo ra một lớp thừa kế từ một lớp khác, bạn sẽ được thừa kế một số phương thức được cài đặt sẵn từ lớp cha. Bạn không nên điều chỉnh hành vi của các phương thức này tại các lớp con. Bạn chỉ nên cài đặt một số phương thức khác được đánh dấu là trừu tượng (abstract) trên lớp cha.
Vì sao?
- Trước tiên, bạn phải tôn trọng ý tưởng của người đi trước. Khi họ tạo ra 1 class, họ đã có một kế hoạc cụ thể chỉ ra phương thức nào được kế thừa không nên sửa, phương thức nào được quyền sửa (virtual), phương thức nào nên được cài đặt ở lớp con (abstract). Bạn nên làm theo.
- Ngược lại nếu không định nghĩa rõ điều này trong thiết kế, rất có thể người tạo ra lớp kế thừa sẽ vô tình thay đổi hành vi của cả chương trình mà không hề biết.
Xin xem ví dụ sau đây: Bạn tạo ra 1 lớp Dice (xúc sắc 6 mặt) như sau:
Người khác muốn tạo ra 1 lớp mới DiceEight (xúc sắc 8 mặt) thừa kế lại Dice để dùng lại property Rnd cho tiện. Nhưng vì xúc sắc mới 8 mặt nên anh ta sửa lại ThrowAValue cho phù hợp như sau:
Tuy nhiên, một tester viết phương thức test class dice của bạn, anh ta không hề biết rằng sẽ có người sẽ sửa vào phương thức ThrowAValue:
Rõ ràng nếu một ai đó dùng phương thức TestDice cho một object thuộc kiểu DiceEight anh ta sẽ gặp lỗi:
Nguyên tắc này thực chất làm cụ thể hơn nguyên tắc 2 Open Close Principle để ràng buộc các lớp con kế thừa lại từ lớp cha nhưng ko sửa đổi hành vi lớp cha. Như đã nói, nguyên tắc khác cũng đều xoay quanh nguyên tắc 2.

Enjoy your coding!

SOLID - Bài 2: Open Closed Principle

List các bài đã viết:
Nguyên tắc cơ bản trong thiết kế OOP: Bài mở đầu Generalization và Specification
SOLID - Bài 1: Single Responsibility Principle (SRP)
SOLID - Bài 2: Open Closed Principle (OCP)
SOLID - Bài 3: Liskov's Substitution Principle (LSP)
SOLID - Bài 4: Interface Segregation Principle (ISP)
SOLID - Bài 5: Dependency Inversion Principle (DIP)

Bài trước bạn đã làm quen với nguyên tắc đầu tiên - Single Responsibility Principle (Đơn Tác Vụ). Hôm nay ta tiếp tục nguyên tắc thứ 2, ứng với chữ cái thứ 2 của SOLID - Open Closed Principle. Tôi tạm dịch là "Nguyên Tắc Đóng và Mở".
Nguyên tắc này được phát biểu như sau:
"Các software entities (như class, modules, functions ...) nên được thiết kế để sẵn sàng mở rộng và hạn chế chỉnh sửa".
Có nghĩa là, chương trình của bạn khi tuân theo nguyên tắc này, một khi gặp yêu cầu mới, bạn sẽ chỉ cần mở rộng tính năng của nó ra thay vì mở code cũ ra để sửa.
Xin xem một ví dụ dưới đây cho rõ hơn.
Giả sử bạn cần thiết kế một chương trình để tính diện tích của một hình phẳng. Các hình cần tính bao gồm: hình tròn và hình vuông. Chương trình của bạn, ở version đầu sẽ như sau:

Vài hôm sau, gã sếp bảo hắn muốn thêm 1 tính năng mới đó là có thể tính diện tích hình chữ nhật nữa. Thế là bạn phải tạo thêm 1 class Rectangle, rồi lại tạo thêm 1 phương thức mới CalculateRectArea chẳng hạn.

Rồi lại một ngày đẹp trời, hắn lại bảo làm thêm cho hắn 1 chức năng tính tổng diện tích của một số hình bao gồm cả 3 loại trên. Thế là bạn lại sửa:

Và rồi, "hắn" lại muốn chương trình của bạn có thể tính thêm vài loại hình quái quỷ gì nữa, chẳng hạn như hình tam giác. Quá mệt mỏi vì lôi ra lôi vào sửa sửa xóa xóa. Bạn rủa gã sếp thậm tệ vì ko nói trước luôn 1 lần mà cứ chơi trò thêm bớt làm bạn cực nhọc.
Thế nhưng, nếu bạn cảm thấy cực nhọc trong vụ này, thì đó không hoàn toàn lỗi của gã kia mà còn một phần là do lỗi thiết kế của bạn. Tại sao ư? Xin hãy xem thiết kế dưới đây, tận dụng triệt để các tính chất của OOP và giải quyết bài toán một cách đẹp đẽ.

Như vậy, nếu có yêu cầu cần tính thêm diện tích cho 1 hình mới ví dụ như hình tam giác chẳng hạn, bạn ko cần phải sửa code hiện có nữa mà chỉ cần thêm 1 class mới Triangle như sau:

That's it. Có vậy thôi! Tới đây, chắc bạn đã hiểu tầm quan trọng của nguyên tắc này. Đây là nguyên tắc mà theo mình là quan trọng nhất trong 5 nguyên tắc, vì "sẵn sàng để mở rộng và hạn chế sửa chữa" là mục tiêu cốt yếu trong architectural design. Tuy nhiên, nguyên tắc này khá khái quát và trừu tượng so với các nguyên tắc còn lại. Thưc ra để hiện thực nguyên tắc này này bạn cần phải kết hợp tất cả các nguyên tắc còn lại một cách nhuần nhuyễn và khéo léo.

Mà thôi, chuyện đó để sau nha, còn bây giờ, enjoy your coding!