SOLID là từ viết tắt dễ nhớ cho một tập hợp các nguyên tắc thiết kế được tạo ra để phát triển phần mềm bằng các ngôn ngữ hướng đối tượng. Các nguyên tắc trong SOLID nhằm thúc đẩy mã đơn giản hơn, mạnh mẽ hơn và có thể cập nhật từ các nhà phát triển phần mềm. Mỗi chữ cái trong SOLID tương ứng với một nguyên tắc để phát triển
Khi được triển khai đúng cách, nó làm cho mã của bạn có thể mở rộng hơn, logic hơn và dễ đọc hơn
Để hiểu các nguyên tắc của SOLID, bạn phải biết rõ cách sử dụng giao diện
Tôi sẽ cố gắng giải thích các Nguyên tắc RẮN trong Python theo cách đơn giản nhất để người mới bắt đầu dễ hiểu. Sẽ rất dễ dàng nếu chỉ lấy các ví dụ được cung cấp và áp dụng chúng vào Python
Hãy đi qua từng nguyên tắc một
1. Nguyên tắc trách nhiệm duy nhấtNguyên tắc Trách nhiệm Đơn yêu cầu rằng một lớp chỉ nên có một công việc. Vì vậy, nếu một lớp có nhiều hơn một trách nhiệm, nó sẽ được ghép nối. Một thay đổi đối với một trách nhiệm dẫn đến sửa đổi một trách nhiệm khác
Chúng tôi có một lớp Người dùng chịu trách nhiệm cho cả thuộc tính người dùng và quản lý cơ sở dữ liệu người dùng. Nếu ứng dụng thay đổi theo cách nó ảnh hưởng đến các chức năng quản lý cơ sở dữ liệu. Các lớp sử dụng thuộc tính Người dùng sẽ phải được chạm và biên dịch lại để bù đắp cho những thay đổi mới. Nó giống như hiệu ứng domino, chạm vào một thẻ, nó ảnh hưởng đến tất cả các thẻ khác trong hàng
Vì vậy, chúng tôi chỉ cần tách lớp, chúng tôi tạo một lớp khác sẽ xử lý một trách nhiệm lưu trữ người dùng vào cơ sở dữ liệu
Một giải pháp phổ biến cho vấn đề nan giải này là áp dụng mẫu Façade. Giới thiệu về Façade pattern bạn có thể đọc thêm. Lớp người dùng sẽ là Mặt tiền để quản lý cơ sở dữ liệu người dùng và quản lý thuộc tính người dùng
2. Nguyên tắc đóng mởCác thực thể phần mềm [Lớp, mô-đun, chức năng] phải được mở để mở rộng, không sửa đổi
Hãy tưởng tượng bạn có một cửa hàng và bạn giảm giá 20% cho những khách hàng yêu thích của mình khi sử dụng lớp này. Khi bạn quyết định giảm gấp đôi 20% cho khách hàng VIP. Bạn có thể sửa đổi lớp như thế này
Không, điều này không tuân theo nguyên tắc OCP. OCP cấm nó. Nếu chúng tôi muốn giảm giá theo phần trăm mới, có thể cho một loại khách hàng khác, bạn sẽ thấy rằng một logic mới sẽ được thêm vào. Để làm cho nó tuân theo nguyên tắc OCP, chúng tôi sẽ thêm một lớp mới sẽ mở rộng Giảm giá. Trong lớp mới này, chúng tôi sẽ thực hiện hành vi mới của nó
Nếu quyết định giảm 80% cho khách hàng siêu vip thì phải thế này
Tiện ích mở rộng không sửa đổi
3. Nguyên tắc thay thế Liskov
Ý tưởng chính đằng sau Nguyên tắc thay thế Liskov là, đối với bất kỳ lớp nào, máy khách sẽ có thể sử dụng bất kỳ kiểu con nào của nó một cách rõ ràng, thậm chí không cần chú ý và do đó không ảnh hưởng đến hành vi dự kiến trong thời gian chạy. Điều này có nghĩa là khách hàng hoàn toàn bị cô lập và không biết về những thay đổi trong hệ thống phân cấp lớp
Chính thức hơn.
Cho q[x] là một thuộc tính chứng minh được về các đối tượng x thuộc loại T. Khi đó q[y] có thể chứng minh được đối với các đối tượng y thuộc loại S trong đó S là một kiểu con của T.
Nói một cách đơn giản hơn có nghĩa là một lớp con, lớp con hoặc chuyên biệt hóa của một đối tượng hoặc lớp phải phù hợp với Lớp cha hoặc Lớp cha của nó
Nhận xét về LSP LSP là nền tảng cho một thiết kế phần mềm hướng đối tượng tốt vì nó nhấn mạnh một trong những đặc điểm cốt lõi của nó - tính đa hình. Đó là về việc tạo ra các hệ thống phân cấp chính xác sao cho các lớp bắt nguồn từ lớp cơ sở là đa hình dọc theo lớp cha, đối với các phương thức trên giao diện của chúng. Cũng rất thú vị khi lưu ý nguyên tắc này liên quan như thế nào đến nguyên tắc trước đó - nếu chúng tôi cố gắng mở rộng một lớp bằng một lớp mới không tương thích, nó sẽ thất bại, hợp đồng với khách hàng sẽ bị phá vỡ và kết quả là một phần mở rộng như vậy
Suy nghĩ cẩn thận về các lớp mới theo cách mà LSP đề xuất sẽ giúp chúng tôi mở rộng hệ thống phân cấp một cách chính xác. Sau đó, chúng ta có thể nói rằng LSP đóng góp cho OCP
4. Nguyên tắc phân tách giao diệnTạo các giao diện chi tiết dành riêng cho khách hàng Khách hàng không nên bị buộc phải phụ thuộc vào các giao diện mà họ không sử dụng. Nguyên tắc này xử lý các nhược điểm của việc triển khai các giao diện lớn
Để minh họa điều này một cách trọn vẹn, chúng ta sẽ lấy một ví dụ kinh điển vì nó rất có ý nghĩa và dễ hiểu. Ví dụ cổ điển
Một mẹo hay khác là trong logic nghiệp vụ của chúng ta, một lớp đơn lẻ có thể triển khai một số giao diện nếu cần. Vì vậy, chúng tôi có thể cung cấp một triển khai duy nhất cho tất cả các phương thức phổ biến giữa các giao diện. Các giao diện tách biệt cũng sẽ buộc chúng ta phải suy nghĩ về mã của mình nhiều hơn từ quan điểm của khách hàng, điều này sẽ dẫn đến sự liên kết lỏng lẻo và dễ dàng kiểm tra. Vì vậy, chúng tôi không chỉ làm cho mã của mình tốt hơn cho khách hàng, mà chúng tôi còn làm cho chính chúng tôi hiểu, kiểm tra và triển khai dễ dàng hơn.
5. Nguyên tắc đảo ngược phụ thuộcSự phụ thuộc nên dựa trên sự trừu tượng hóa chứ không phải sự cụ thể hóa. Các mô-đun cấp cao không nên phụ thuộc vào các mô-đun cấp thấp. Cả hai lớp cấp thấp và cấp cao đều phụ thuộc vào cùng một sự trừu tượng hóa. Trừu tượng không nên phụ thuộc vào chi tiết. Chi tiết nên phụ thuộc vào sự trừu tượng
Có một điểm trong quá trình phát triển phần mềm, nơi ứng dụng của chúng tôi sẽ bao gồm phần lớn các mô-đun. Khi điều này xảy ra, chúng ta phải giải quyết mọi thứ bằng cách sử dụng phép nội xạ phụ thuộc. Các thành phần cấp cao phụ thuộc vào các thành phần cấp thấp để hoạt động. Để tạo hành vi cụ thể, bạn có thể sử dụng các kỹ thuật như kế thừa hoặc giao diện