Series SOLID cho thanh niên code CỨNG: Single Responsibility Principle

Cách đây khá lâu, mình đã có một bài viết tổng quát về SOLID Principle, những nguyên lý thiết kế OOP. Nhắc lại một chút cho các bạn đã quên.

Đây là những nguyên lý được đúc kết bởi máu xương vô số developer, rút ra từ hàng ngàn dự án thành công và thất bại. Một project áp dụng những nguyên lý này sẽ có code dễ đọc, dễ test, rõ ràng hơn. Và việc quan trọng nhất là việc maintainace code sẽ dễ hơn rất nhiều.

Nắm vững những nguyên lý này, đồng thời áp dụng chúng trong việc thiết kế + viết code sẽ giúp bạn tiến thêm 1 bước trên con đường thành senior nhé (1 ông senior bên FPT Software từng bảo mình thế).

7 Likes

Mình nghĩ bài viết nên thêm một chút về trade-off giữa cách viết single responsibility và cách viết thông thường, và kinh nghiệm nên responsibility tới đâu (vì ngay cái class Formater và Store cũng chưa thực sự là Single Responsibility vì nó cũng chứa 3 hàm ^^, đáng nhẽ phải là HTMLFormater, JsonFormater, …)

Ví dụ như trade-off:

  • Phân mảnh class khá nhiều. Với 1 app mà có hàng ngàn class như vậy khiến việc debug cũng cực kỳ khó khăn.
  • Trong thực tế sản xuất phần mềm, việc implement Single Responsibility phải đánh đổi với performance. Ví dụ, bạn có 1 class Logger, giờ muốn Log từng chức năng như DBLogger, NetworkLogger, 3rdLogger, nếu extends từ Logger thì mỗi class này sẽ có thêm các tính năng của Logger (vi phạm Single Responsibility), do đó buộc phải thiết kế Decorator (ít nhất phải thêm vài class nữa)
3 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?