Solid Principles: Liskov Substitution Principle

Hôm nay chúng ta tiếp tục tìm hiểu về chữ L trong nguyên tắc SOLID. Liskov Substitution Principle.

Bất cứ instance nào của class cha cũng có thể được thay thế bởi instance của class con của nó mà không làm thay đổi tính đúng đắn của chương trình

Cảnh báo: Đây là một trong những nguyên tắc tương đổi trừu tượng và gây nhiều tranh cãi. Đọc nhiều có thể gây tẩu hoả nhập ma.

Để nói cho dễ hiểu, hôm nay chúng ta cùng đem Chim ra để bàn luận.
Đây là 1 ví dụ vi phạm nguyên tắc LSP

Ta cần viết một hàm mô tả chim bay. Eagle, Dove thì bay được còn Penis thì không bay được.
Do Penis cũng là chim nên cũng được kế thừa class Bird. Nhưng do Penis không bay được nên khi gọi hàm Fly ta sẽ quăng ra NoFlyException.

public class Bird {
  public virtual void Fly() { Console.Write("Fly"); }
}
public class Eagle : Bird {
  public override void Fly() { Console.Write("Eagle Fly"); }
}
public class Dove : Bird {
  public override void Fly() { Console.Write("Dove Fly"); }
}
public class Penis : Bird {
  public override void Fly() { throw new NoFlyException(); }
}
 
var birds = new List { new Bird(), new Eagle(), new Dove(), new Penis() };
foreach(var bird in birds) bird.Fly(); 
// Tới penis thì lỗi vì cánh cụt quăng Exception

Ta duyệt mảng birds và chạy thì Penis gây lỗi. Penis không thể thay thế được cho Bird nên nó vi phạm LSP.

Vậy ta phải làm gì?. Có lẽ thiết kế này đã sai Penis không nên kế thừa Bird. Nó nên là một cái gì đấy khác để chương trình không bị lỗi khi chạy. Không vi pham LSP.

Đôi khi ta thắc mắc. Sao lại phải thiết kế rườm rà và phức tạp đến vậy. Rồi mấy cái nguyên tắc gì mà đọc đau hết cả đầu.
Làm đơn giản cũng được mà.

Nếu chương trình nhỏ, ít người phát triển, không có nhu cầu mở rộng thì bạn có thể làm thế nào tuỳ bạn. Ở đây chúng ta hướng đến những chương trình lớn, dễ mở rộng, dễ bảo trì và chắc chắn là sẽ có rất nhiều người cùng phát triển.
Để đảm bảo cả team cùng kiểm soát logic tốt thì chúng ta nên áp dụng những nguyên tắc. Nếu không sử dụng có thể chương trình của bạn vẫn pass test nhưng lại bị lỗi khi khách hàng sử dụng. Điều này cực kì nguy hiểm.

Tất nhiên nguyên tắc vẫn chỉ là nguyên tắc. Nó không phải pháp luật hay kỷ luật gì cả. Sử dụng hay không là tuỳ bạn.
Dùng thì cũng phải cân nhắc kĩ lưỡng, cũng cần có kinh nghiệm để áp dụng đúng cách đem lại lợi ích. Đôi khi không phải cứ áp dụng là thành công.
Chúc các bạn may mắn
Ở bài sau chúng ta sẽ tiếp tục tìm hiểu nguyên tắc thứ 4 Interface Segregation Principle nguyên lý phân tách interface
Các bạn cùng đón đọc nhé.