30/09/2018, 20:43

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ế).

Từ coder đến developer - Tôi đi code dạo – 2 May 16

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ố …

Phan Hoàng viết 22:59 ngày 30/09/2018

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)
…

Bình luận về bài viết này

Chia sẻ tin đăng đến bạn bè

Gửi Messenger

Bài liên quan

Huy Hoàng Phạm

0 chủ đề

0 bài viết

Tác giả nổi bật