CẢI THIỆN MÃ CỦA BẠN VỚI NGUYÊN TẮC SOLID

November 26, 2019

CẢI THIỆN MÃ CỦA BẠN VỚI NGUYÊN TẮC SOLID

 

Có rất nhiều kinh nghiệm được tích lũy trong quá trình làm việc của các nhà phát triển phần mềm. Bất kể kinh nghiệm của họ là gì, họ luôn có cách để đối phó với những thiếu sót của tất cả mẫu chương trình. Bài viết hôm nay sẽ đem đến cho bạn một nguyên tắc giúp cải thiện mã của bạn, dựa trên Lập trình hướng đối tượng được gọi là nguyên tắc Solid.

 

 

SOLID có nghĩa là gì?

 

SOLID là một từ viết tắt của một kỹ thuật học tập giúp làm cho một cái gì đó dễ nhớ hơn. Mỗi chữ cái trong SOLID đại diện cho một nguyên tắc. Bao gồm:

 

- Single Responsibility Principle (Nguyên tắc đơn nhiệm)

- Open-Closed Principle (Nguyên tắc đóng-mở)

- Liskov Substitution Principle (Nguyên tắc thay thế)

- Interface Segregation Principle (Nguyên tắc phân chia giao diện)

- Dependency Inversion Principle (Nguyên tắc đảo ngược phụ thuộc)

 

Vậy những nguyên tắc này giúp ích gì cho chúng ta, hãy cùng tìm hiểu ngay dưới đây.

 

Single Responsibility Principle: Nguyên tắc đơn nhiệm (SRP)

 

Một đối tượng nên chịu một trách nhiệm cụ thể nào đó - nguyên tắc đơn nhiệm (nguyên tắc Solid)

 

Nói ngắn gọn, nguyên tắc đơn nhiệm (SRP) cho chúng ta biết rằng một đối tượng nên chịu một trách nhiệm cụ thể nào đó.

 

 

 

"Một lớp (class) chỉ nên có một lý do để thay đổi"_ Theo George C. Martin

 

"Một lý do để thay đổi? Nhưng nếu một lớp hoàn toàn phù hợp để theo dõi hai điều cùng một lúc thì sao?"

 

Nếu một lớp được thiết kế để phân tích một dữ liệu và sau đó hiển thị nó cho người dùng, thì nó thực sự có hai lý do để tồn tại và do đó nó có hai lý do để thay đổi. Nội dung dữ liệu có thể thay đổi hoặc định dạng của dữ liệu có thể thay đổi. Theo SRP, hai trách nhiệm này được chia thành hai lớp khác nhau, mỗi lớp có một lý do duy nhất để tồn tại.

 

Open-Closed Principle: Nguyên tắc đóng-mở (OCP)

 

Nguyên tắc đóng- mở trong nguyên tắc Solid phát biểu rằng các thực thể phần mềm nên được mở để mở rộng, nhưng đóng để sửa đổi.

 

Điều này giúp người khác dễ dàng tiếp tục xây dựng công việc của bạn hơn bằng cách thêm nhiều chức năng hơn vào một lớp mới dựa trên những gì bạn đã làm từ trước.

 

Mặt khác, bạn thường không muốn mã của mình mở đến mức nhà phát triển khác có thể ghi đè lên làm ảnh hưởng đến các phần còn lại của chương trình.

 

Về cơ bản, nguyên tắc này được hiểu là: điều chỉnh quyền truy cập là tốt. Người khác sẽ có quyền truy cập nhưng trong tầm kiểm soát, quyền này không bị hạn chế đến mức nó sẽ lấy đi hết những lợi ích của việc sử dụng mã của bạn.

 

Liskov Substitution Principle: Nguyên tắc thay thế (LSP)

 

Ý tưởng này được Barbara Liskov đưa ra vào năm 1987, và thông điệp chính của nó là khéo léo trong cách đơn giản. Bất cứ khi nào một loại T có một lớp con của loại S, người ta sẽ có thể thay thế T bằng S mà không làm thay đổi tính chính xác của chương trình.

 

 

 

Giả sử bạn có một lớp hình chữ nhật, với công thức tính diện tích của nó. Nếu bạn đã thêm một lớp hình vuông được kế thừa từ hình chữ nhật, hình vuông thực sự sẽ có thể thay thế đối tượng hình chữ nhật mà không làm hỏng kết quả. Có một mối quan hệ giữa hai hình làm chương trình trở nên khả thi, vì hình vuông là một loại hình chữ nhật đặc biệt.

 

Tuy nhiên, nếu tạo thêm một lớp hình tròn và biến nó thành một lớp con của Hình chữ nhật lại là một điều không mấy khả thi. Chủ yếu là vì cách tính diện tích hình chữ nhật và hình tròn là khác nhau và chúng dường như cũng không có mối quan hệ gì với nhau. Hình tròn và hình chữ nhật có thể phù hợp với giao thức hình dạng, nhưng chúng không phù hợp để phân lớp theo cách trên.

 

Interface Segregation Principle: Nguyên tắc phân chia giao diện (ISP)

 

Chữ I trong nguyên tắc Solid thể hiện rằng không có khách hàng nào bị buộc phải phụ thuộc vào các thuộc tính hoặc phương pháp mà họ không sử dụng hoặc không cần.

 

Một ví dụ rất hay minh họa cho nguyên tắc này là giao thức phổ biến Swift protocol Codable. Chúng chỉ xác định hai phương thức, một phương thức khởi tạo một đối tượng mới từ bộ giải mã và một phương thức mã hóa một đối tượng sang bộ mã hóa, các kỹ sư Swift có thể dễ dàng dừng lại khi cần.

 

Tuy nhiên, ai đó đã nghĩ ra rằng mã hóa và giải mã là hai quá trình rất khác nhau, mặc dù chúng có rất nhiều điểm chung. Giải pháp là tách phương thức thành hai giao thức khác nhau là mã hóa (Encodable) và giải mã (Decodable), và biến Codable thành một thành phần của hai giao thức đó. Bằng cách này, các nhà phát triển chỉ quan tâm đến việc giải mã thông tin sẽ không bị buộc phải thực hiện phần mã hóa và ngược lại.

 

Dependency Inversion Principle: Nguyên tắc đảo ngược phụ thuộc (DIP)

 

Nguyên tắc đảo ngược phụ thuộc trong nguyên tắc Solid quy định rằng người ta nên phụ thuộc vào cái chung tổng quát, chứ không phải cái riêng cụ thể.

 

Hãy tưởng tượng rằng chúng ta đang tạo một lớp sẽ lưu trữ rất nhiều số. Chúng ta có thể tạo một biến kiểu ArrayList và sử dụng biến đó để lưu trữ các số của mình, nhưng sau đó chúng ta tự đưa mình vào ngõ cụt. Điều gì sẽ xảy ra nếu sau này chúng ta nhận ra rằng ArrayList không phải là lựa chọn tốt nhất và bây giờ chúng ta phụ thuộc vào các phương thức cụ thể của lớp đó trong khi các lớp khác lại không có?

 

Giải pháp cho vấn đề trên là tạo một biến kiểu List. Vì List là một giao diện chứ không phải là một lớp cụ thể. Do đó, việc thay thế lớp sau này sẽ dễ dàng như việc thay đổi một dòng mã.

 

Hi vọng nguyên tắc Solid được nhắc đến trên đây có thể phần nào đó giúp bạn cải thiện khả năng viết mã của mình. Hãy đọc và nghiên cứu thật kỹ chúng để rút ra những kinh nghiệm cho bản thân sau này nhé.

Nguồn Tổng hợp

 

 

---

JT1 - IT Recruitment Agency
Website:
https://www.jt1.vn
Email: hi@jt1.vn
Điện thoại: +8428 6675 6685
Xem thêm các bài viết khác tại: https://www.jt1.vn/blog
Theo dõi chúng tôi tại: https://www.facebook.com/jt1asia/

Please reload

Recent Posts

Please reload

banner-top-it-job-right.gif

Archive

Please reload

Tags