Các nguyên lý trong thiết kế phần mềm
Bài viết được sự cho phép của tác giả Tino Phạm
Các nguyên lý thiết kế phần mềm là những hướng dẫn giúp cho nhà phát triển phần mềm (developers) tạo ra được một thiết kế hệ thống tốt. Chúng ta có các nguyên lý trong thiết kế phần mềm như: SOLID, DRY, KISS, YAGNI.
Lưu ý: đây là các nguyên lý chứ không phải là luật. Nghĩa là bạn phải nên cân nhắc và hiểu rõ khi nào nên áp dụng cho đúng.
SOLID
Chúng ta cùng tìm hiểu về nguyên lý SOLID. Nội dung chính của nguyên lý này được kết hợp từ 5 nguyên lý cơ bản sau:
1. Single Responsibility Priciple:
Đây là nguyên lý đầu tiên (chính là chữ S đầu trong SOLID). Nguyên lý này nói rằng không nên có hơn 1 lý do để một lớp (class) thay đổi. Nghĩa là, bạn nên thiết kế class của bạn sao cho mỗi class chỉ phục vụ cho một mục đích.
Ví dụ: Một kịch bản như sau, chúng ta cần một tính năng lên lịch hẹn phỏng vấn ứng viên (schedule interview). Công việc chúng ta cần làm là: lưu thông tin buổi phỏng vấn, sau đó gửi mail cho ứng viên về buổi phỏng vấn. Thay vì thiết kế một class ScheduleInterview để làm tất cả các việc trên, bạn tạo một class Interview chỉ để thực hiện công việc lưu thông tin buổi phỏng vấn, và chúng ta có thêm class EmailSending dùng để thực hiện công việc gửi mail cho ứng viên.
2. Open/Closed Priciple:
Đây là nguyên lý thứ hai (chính là chữ O trong SOLID). Nguyên lý này nói rằng các thực thể phần mềm như: classs, modules, functions,… thì có thể thoải mái viết code để mở rộng nhưng hạn chế cho việc sửa đổi.
Từ “Closed” ở đây nghĩa là, một module đã được phát triển và tested thì code của nó chỉ được thay đổi để sửa lỗi.
Từ “Open” nghĩa là module có thể dễ dàng và thoải mái được mở rộng từ code hiện tại để phục vụ cho tính năng mới.
Ví dụ: một lớp cơ sở PaymentGatewayBase chứa tất cả các thuộc tính và phương thức thanh toán cơ bản. Lớp này có thể được mở rộng bởi các lớp PaymentGateway khác nhau cho các nhà cung cấp cổng thanh toán khác nhau để phục vụ các chức năng của họ. Do đó, nó được mở rộng dễ dàng và thoải mái nhưng hạn chế việc thay đổi.
3. Liscov Substitution Priciple:
Nguyên ly này nói rằng các đối tượng của lớp con có thể thay thế được các đối tượng của lớp cha mà vẫn đảm bảo tính đúng đắn của chương trình.
Nói cho dễ hiểu thì chỉ cho class A kế thừa class B khi class A thay thế được class B.
Nguyên lý này là cách để đảm bảo rằng kế thừa được sử dụng đúng cách.
Ví dụ:
– Một ví dụ cho trường hợp vi phạm nguyên lý này như sau. Giả sử chúng ta có một lớp Chim với một phương thức là Bay(). Như vậy, chúng ta có thể nói rằng 3 lớp ChimHảiÂu, ChimSáo, ChimCánhCụt đều là Chim nên chúng ta sẽ cho chúng kế thừa lớp Chim. Tuy nhiên, khi gọi Bay() thì ChimHaiAu và ChimSao chạy tốt, còn ChimCanhCut quăng lỗi vì chim cánh cụt thì không bay được.
– Giả sử chúng ta có class Student kế thừa từ class Person. Vậy theo nguyên lý này thì bất cứ nơi nào có thể dùng Person thì cũng có thể dùng Student, bởi vì Student là class con của Person.
– Trong C# chúng ta có thể dùng ForEach với List, ArrayList, LinkedList bởi vì chúng được kế thừa từ interface IEnumerable. Các class List, ArrayList,… được thiết kế đúng LSP nên chúng có thể thay thế cho IEnumerable.
4. Interface Segregation Priciple:
Nguyên lý này nói rằng 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ể.
Ví dụ: nếu chúng ta có một interface với 20 phương thức (method), vậy thì những class implement sẽ phải implement toàn bộ 20 methods này, kể cả những methods mà nó không bao giờ sử dụng đến. Áp dụng nguyên lý này, chúng ta sẽ chia nhỏ interface lớn này ra thành những interfaces nhỏ hơn, các class chỉ cần implement những interface có chức năng mà chúng cần, không cần implement những methods mà chúng không sử dụng.
5. Dependency Inversion Priciple (DIP):
Nguyên lý này nói rằng, các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc vào abstractions (interface).
Abstractions (Interface) không nên phục thuộc vào chi tiết, mà chi tiết nên phụ thuộc vào abstractions (interface). Nghĩa là, Các class nên giao tiếp với nhau thông qua interface, không phải thông qua implementation.
Ví dụ: Dependency Injection pattern là một implementation của nguyên lý này.
DRY – Don’t Repeat Yourself
Nguyên lý này nói rằng mỗi mẩu kiến thức nhỏ (code) chỉ có thể xảy ra chính xác một lần trong toàn bộ hệ thống. Điều này giúp chúng ta viết mã mở rộng, bảo trì và có thể sử dụng lại được.
KISS – Keep it simple, Stupid!
Nguyên lý này nói rằng cố gắng giữ cho từng phần nhỏ của phần mềm đơn giản và nên tránh phức tạp chúng không cần thiết. Điều này giúp chúng ta viết code dễ bảo trì.
YAGNI – You ain’t gonna need it
Nguyên lý này nói rằng luôn luôn thực hiện những điều khi bạn thực sự cần chúng, không bao giờ thực hiện mọi thứ trước khi bạn cần chúng.
Bài viết gốc được đăng tải tại thangphampt.wordpress.com
Có thể bạn quan tâm:
- Các khái niệm căn bản trong kiến trúc phần mềm
- Inversion of Control nguyên lý của các nguyên lý
- Những tựa sách nổi tiếng dành cho Software Developer – Phần 1
Xem thêm Việc làm Developer hấp dẫn trên Station D
Bạn có thể quan tâm
- Hiểu về trình duyệt – How browsers work(Công Nghệ)
- Applicant Tracking System là gì? ATS hoạt động ra sao(Cẩm Nang Tuyển Dụng)
- Tôi không phải là lập trình viên thực sự?(Công Nghệ)
