Nhiều người hỏi tại sao mình copy rất nhiều bài viết khác nhau rồi đăng lên các article. Mình nghĩ câu trả lời cho việc này đó chính là tự nhắc bản thân luôn nhớ những kiến thức này và là sự sharing để học hỏi và học tập lẫn nhau cũng là mục đích chính của social network này. 

Người giỏi không hẳn là người luôn phát minh ra những cái mới mà đó chính là người biết đứng trên những đôi vai lớn hơn và góp phần duy trì phát triển nó. Câu nói cũng là copy nên mọi người đừng gạch đá mình nhé Smile .

Đây là một article nói về những nguyên tắc thiết kế cơ bản của một project dù lớn hay nhỏ thì nó luôn đúng. Gọi tắt là S.O.L.I.D



  1. Single responsibility principle

  2. Open/closed principle

  3. Liskov substitution principle

  4. Interface segregation principle

  5. Dependency inversion principle

 


1. Single responsibility principle


 


Một class chỉ nên giữ 1 trách nhiệm duy nhất (Chỉ có thể sửa đổi 

class với 1 lý do duy nhất)

Đây là một ví dụ minh hoạ cho sự vi phạm nguyên tắc đầu tiên

public class ReportManager()

{

   public void ReadDataFromDB();

   public void ProcessData();

   public void PrintReport();

}

Class này giữ tới 3 trách nhiệm: Đọc dữ liệu từ DB, xử lý dữ liệu, in kết quả. Do đó, chỉ cần ta thay đổi DB, thay đổi cách xuất kết quả, … ta sẽ phải sửa đổi class này. Càng về sau class sẽ càng phình to ra. Theo đúng nguyên lý, ta phải tách class này ra làm 3 class riêng. Tuy số lượng class nhiều hơn những việc sửa chữa sẽ đơn giản hơn, class ngắn hơn nên cũng ít bug hơn.


2. Open/closed principle


Có thể thoái mái mở rộng 1 class, nhưng không được sửa đổi

bên trong class đó (open for extension but closed for modification).

Theo nguyên lý này, mỗi khi ta muốn thêm chức năng,.. cho chương trình, chúng ta nên viết class mới mở rộng class cũ ( bằng cách kế thừa hoặc sở hữu class cũ) không nên sửa đổi class cũ.

3. Liskov Substitution Principle


Trong một chương trình, các object của class con có thể

thay thế class cha mà không làm thay đổi
tính đúng đắn của chương trình


Hơi khó hiểu? Không sao, lúc mới đọc mình cũng vậy. Hãy tưởng tượng bạn có 1 class cha tên Vịt. Các class VịtBầu, VịtXiêm có thể kế thừa class này, chương trình chạy bình thường. Tuy nhiên nếu ta viết class VịtChạyPin, cần pin mới chạy được. Khi class này kế thừa class Vịt, vì không có pin không chạy được, sẽ gây lỗi. Đó là 1 trường hợp vi phạm nguyên lý này.



4. Interface Segregation Principle


Thay vì dùng 1 interface lớn, ta nên tách thành nhiều

interface nhỏ, với nhiều mục đích cụ thể


Nguyên lý này khá dễ hiểu. Hãy tưởng tượng chúng ta có 1 interface lớn, khoảng 100 methods. Việc implements sẽ khá cực khổ, ngoài ra còn có thể dư thừa vì 1 class không cần dùng hết 100 method. Khi tách interface ra thành nhiều interface nhỏ, gồm các method liên quan tới nhau, việc implement + quản lý sẽ dễ hơn.

5. Dependency inversion principle


1. Các module cấp cao không nên phụ thuộc vào các modules cấp thấp. 

Cả 2 nên phụ thuộc vào abstraction.
2. Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại.
( Các class giao tiếp với nhau thông qua interface,
không phải thông qua implementation.)


Nguyên lý này khá lắt léo, mình sẽ lấy ví dụ thực tế. Chúng ta đều biết 2 loại đèn: đèn tròn và đèn huỳnh quang. Chúng cùng có đuôi tròn, do đó ta có thể thay thế đèn tròn bằng đèn huỳnh quanh cho nhau 1 cách dễ dàng.

Ở đây, interface chính là đuôi tròn, implementation là bóng đèn tròn,bóng đèn huỳnh quang. Ta có thể swap dễ dàng giữa 2 loại bóng vì ổ điện chỉ quan tâm tới interface (đuôi tròn), không quan tâm tới implementation.


Lời kết: (cái này do bản thân mình suy nghĩ sau khi đọc bài từ tác giả)

Thật ra việc áp dụng những nguyên lý trên chính là một cách tránh những sai lầm trong việc thiết kế mà những người đi trước gặp phải. Tuy nhiên theo chút kinh nghiệm non nớt của bản thân nhận thấy, tuỳ vào ngữ cảnh mà ta áp dụng cũng đừng nên áp dụng đến mức làm mã nguồn trở nên quá khó hiểu hay quá cồng kềnh. Và hơn nữa viẹc áp dụng những nguyên lý trên còn bao gồm những design pattern để có thể đảm bảo sự đúng và chính xác cho nguyên lý.

Cảm ơn mọi người đã đọc. và cảm ơn tác giả bài viết đã cho ta cách nhìn khái quát hơn về cách xây dựng hệ thống tốt nhất + chi phí bảo trì, phát triển ít tốn kém hơn.

Good night Smile



 




 

 

 

 

 

Login để lấy link download