Tôi thường gặp những nhà phát triển chưa từng nghe đến nguyên tắc SOLID (chúng tôi . — Dịch.) hoặc lập trình hướng đối tượng (OOP), hoặc đã nghe nói đến nhưng không sử dụng chúng trong thực tế. Bài viết này mô tả những lợi ích của nguyên tắc OOP giúp ích cho nhà phát triển trong công việc hàng ngày của mình. Một số trong số chúng được nhiều người biết đến, số khác thì không nhiều, vì vậy bài viết sẽ hữu ích cho cả người mới bắt đầu và lập trình viên có kinh nghiệm.
Chúng tôi nhắc nhở: dành cho tất cả độc giả của Habr - giảm giá 10 rúp khi đăng ký bất kỳ khóa học Skillbox nào bằng mã khuyến mãi Habr.
Hộp kỹ năng khuyến nghị: Khóa học giáo dục trực tuyến .
KHÔ (Đừng lặp lại chính mình)
Một nguyên tắc khá đơn giản, bản chất của nó đã rõ ngay từ cái tên: “Đừng lặp lại chính mình”. Đối với một lập trình viên, điều này có nghĩa là cần tránh mã trùng lặp, cũng như cơ hội sử dụng tính trừu tượng trong công việc của họ.
Nếu có hai phần lặp lại trong mã, chúng nên được kết hợp thành một phương thức. Nếu một giá trị mã hóa cứng được sử dụng nhiều lần thì cần chuyển đổi nó thành hằng số công khai.
Điều này là cần thiết để đơn giản hóa mã và giúp bảo trì dễ dàng hơn, đó là mục tiêu chính của OOP. Bạn cũng không nên lạm dụng liên minh vì cùng một mã sẽ không vượt qua được quá trình xác minh với cả OrderId và SSN.
Đóng gói các thay đổi
Hầu hết các sản phẩm phần mềm của công ty đều không ngừng phát triển. Điều này có nghĩa là những thay đổi cần phải được thực hiện đối với mã, nó cần được hỗ trợ. Bạn có thể làm cho cuộc sống của mình dễ dàng hơn bằng cách sử dụng tính năng đóng gói. Điều này sẽ cho phép bạn kiểm tra và duy trì cơ sở mã hiện có của mình hiệu quả hơn. .
Nếu bạn viết bằng Java thì .
Nguyên lý đóng/mở
Bạn có thể dễ dàng ghi nhớ nguyên tắc này bằng cách đọc câu lệnh sau: “Các thực thể phần mềm (lớp, mô-đun, hàm, v.v.) phải mở để mở rộng nhưng đóng để sửa đổi”. Trong thực tế, điều này có nghĩa là họ có thể cho phép thay đổi hành vi của mình mà không cần thay đổi mã nguồn.
Nguyên tắc này rất quan trọng khi những thay đổi đối với mã nguồn yêu cầu phải sửa đổi mã, kiểm tra đơn vị và các thủ tục khác. Mã tuân theo nguyên tắc mở/đóng không thay đổi khi được mở rộng, do đó có ít vấn đề hơn với nó.
Đây là một ví dụ về mã vi phạm nguyên tắc này.
Nếu bạn cần thay đổi thứ gì đó trong đó, sẽ mất rất nhiều thời gian, vì tất cả các phần của mã có kết nối với đoạn mong muốn sẽ phải được thay đổi.
Nhân tiện, tính mở-đóng là một trong những nguyên tắc của SOLID.
Nguyên tắc trách nhiệm duy nhất (SRP)
Một nguyên tắc khác từ bộ SOLID. Nó nói rằng “chỉ có một nguyên nhân gây ra sự thay đổi trong giai cấp”. Cả lớp chỉ giải quyết được một vấn đề. Nó có thể có một số phương pháp, nhưng mỗi phương pháp chỉ được sử dụng để giải quyết một vấn đề chung. Tất cả các phương thức và thuộc tính chỉ nên phục vụ điều này.
Giá trị của nguyên tắc này là nó làm lỏng mối liên kết giữa thành phần phần mềm riêng lẻ và mã. Nếu bạn thêm nhiều chức năng vào một lớp, nó sẽ đưa ra mối quan hệ giữa hai chức năng. Vì vậy, nếu bạn thay đổi một trong số chúng, có khả năng cao sẽ làm hỏng cái thứ hai, được kết nối với cái thứ nhất. Và điều này có nghĩa là tăng chu kỳ thử nghiệm để xác định trước mọi vấn đề.
Nguyên tắc đảo ngược phụ thuộc (DIP)
Trên đây là ví dụ về mã trong đó AppManager phụ thuộc vào EventLogWriter, do đó được kết hợp chặt chẽ với AppManager. Nếu bạn cần một cách khác để hiển thị thông báo, có thể là thông báo đẩy, SMS hoặc email, bạn cần thay đổi lớp AppManager.
Vấn đề có thể được giải quyết bằng cách sử dụng DIP. Vì vậy, thay vì AppManager, chúng tôi yêu cầu EventLogWriter, sẽ được nhập bằng khung.
DIP giúp bạn có thể dễ dàng thay thế các mô-đun riêng lẻ bằng các mô-đun khác bằng cách thay đổi mô-đun phụ thuộc. Điều này cho phép thay đổi một mô-đun mà không ảnh hưởng đến các mô-đun khác.
Thành phần thay vì kế thừa
Có hai cách chính để sử dụng lại mã: kế thừa và hợp thành, cả hai đều có ưu điểm và nhược điểm riêng. Thông thường cái thứ hai được ưa thích hơn vì nó linh hoạt hơn.
Tính năng kết hợp mang lại cho bạn khả năng thay đổi hành vi của một lớp trong thời gian chạy bằng cách đặt các thuộc tính của lớp đó. Khi triển khai các giao diện, tính đa hình được sử dụng, giúp triển khai linh hoạt hơn.
Ngay cả Java hiệu quả của Joshua Bloch cũng khuyên nên chọn thành phần thay vì kế thừa.
Nguyên tắc thay thế Barbara Liskov (LSP)
Một nguyên tắc khác từ bộ công cụ SOLID. Nó tuyên bố rằng các kiểu con phải thay thế được cho siêu kiểu. Nghĩa là, các phương thức và hàm hoạt động với siêu lớp sẽ có thể hoạt động mà không gặp vấn đề gì với các lớp con của nó.
LSP gắn liền với cả nguyên tắc trách nhiệm duy nhất và nguyên tắc trách nhiệm chung. Nếu một lớp cung cấp nhiều chức năng hơn một lớp con thì lớp sau sẽ không hỗ trợ một số chức năng, vi phạm nguyên tắc này.
Đây là một đoạn mã mâu thuẫn với LSP.
Phương thức Area(Rectangle r) tính diện tích của Hình chữ nhật. Chương trình sẽ bị lỗi sau khi thực thi Square vì Square ở đây không phải là Rectangle. Theo nguyên tắc LSP, các hàm sử dụng tham chiếu đến lớp cơ sở sẽ có thể sử dụng các đối tượng của lớp dẫn xuất mà không cần hướng dẫn bổ sung.
Nguyên tắc này, là một định nghĩa cụ thể của một kiểu con, đã được Barbara Liskov đề xuất trong bài phát biểu quan trọng của hội nghị năm 1987 có tựa đề “Trừu tượng dữ liệu và phân cấp”, do đó có tên như vậy.
Nguyên tắc tách giao diện (ISP)
Một nguyên tắc RẮN khác. Theo đó, một giao diện không được sử dụng thì không nên triển khai. Việc tuân theo nguyên tắc này giúp hệ thống vẫn linh hoạt và phù hợp cho việc tái cấu trúc khi có thay đổi về logic vận hành.
Thông thường, tình huống này xảy ra khi giao diện chứa một số chức năng cùng một lúc và khách hàng chỉ cần một trong số chúng.
Vì viết giao diện là một công việc khó khăn nên việc thay đổi nó sau khi công việc hoàn thành mà không làm hỏng bất cứ điều gì sẽ là một thách thức.
Ưu điểm của nguyên tắc ISP trong Java là tất cả các phương thức phải được triển khai trước và chỉ sau đó chúng mới có thể được các lớp sử dụng. Do đó, nguyên tắc giúp giảm số lượng phương pháp.
Lập trình cho giao diện, không phải cho việc triển khai
Mọi thứ ở đây đều rõ ràng ngay từ cái tên. Áp dụng nguyên tắc này dẫn đến việc tạo ra mã linh hoạt có thể hoạt động với bất kỳ triển khai giao diện mới nào.
Bạn nên sử dụng loại giao diện cho các biến, kiểu trả về hoặc kiểu đối số phương thức. Một ví dụ là sử dụng SuperClass thay vì SubClass.
Đó là:
Danh sách số= getNumbers();
Nhưng không:
Số ArrayList = getNumbers();
Đây là một triển khai thực tế của những gì được thảo luận ở trên.
nguyên tắc ủy nhiệm
Một ví dụ phổ biến là các phương thức Equals() và hashCode() trong Java. Khi cần so sánh hai đối tượng, hành động này được ủy quyền cho lớp tương ứng thay vì lớp khách.
Ưu điểm của nguyên tắc này là không có sự trùng lặp mã và việc thay đổi hành vi tương đối đơn giản. Nó cũng áp dụng cho việc ủy quyền sự kiện.
Tất cả những nguyên tắc này cho phép bạn viết mã linh hoạt, đẹp và đáng tin cậy hơn với độ gắn kết cao và độ ghép thấp. Tất nhiên, lý thuyết là tốt, nhưng để một nhà phát triển thực sự sử dụng được kiến thức đã học thì cần phải thực hành. Khi bạn đã nắm vững các nguyên tắc OOP, bước tiếp theo của bạn có thể là tìm hiểu các mẫu thiết kế để giải quyết các vấn đề phát triển phần mềm phổ biến.
Hộp kỹ năng khuyến nghị:
- khóa học thực hành .
- Khóa học trực tuyến được áp dụng .
- Khóa học thực hành hai năm .
Nguồn: www.habr.com