Low coupling và high cohesion là 2 nằm trong tính đi với nhau như là phương châm cần giành được trong thiết kế, trong nội dung bài viết này, cùng tìm hiểu xem chúng là gì, làm sao để đạt được và nên tránh các lỗi liên quan đến coupling và cohesion khi xây cất phần mềm.Bạn vẫn xem: Loose coupling là gì

COUPLING

Low couplingloose coupling hay high coupling và tight coupling, ắt hẳn ai trong chúng ta khi học về các nguyên lý lập trình sẵn căn bản đều biết về khái niệm coupling này. Coupling đề cập mang lại vấn đề dựa vào lẫn nhau giữa các component. Low coupling, loose coupling tức là các component ít dựa vào vào nhau, sự biến hóa trong component này ít khi, hoặc không tác động đến component kia. Ngược lại, high coupling cùng tight coupling cho biết các component dựa vào nhiều vào nhau, khi biến đổi 1 component thì các component kia mọi bị tác động và có công dụng phải chuyển đổi theo. Vớ nhiên, low coupling là mục tiêu chúng ta cần hướng đến để bảo đảm an toàn cho khối hệ thống ít bị ảnh hưởng khi có thay đổi và do đó, tăng tốc độ thực hiện quá trình và bảo trì.

Bạn đang xem: Loose coupling là gì


*

Nếu họ nhìn vào hình trên, nó cho họ thấy một mối tương tác giữa hai class được call là tight coupling. Class1 nghỉ ngơi trên tạo thành các đối tượng người sử dụng của Class2 trực tiếp, và thậm chí là đi mang đến các trở thành viên và truy cập vào. Điều này khiến cho nó rất phụ thuộc vào vào Class2. Điều gì sẽ xẩy ra nếu chúng ta quyết định rằng chúng ta muốn thêm tham số cấp dưỡng trong constructor của Class2 và đặt mang định là private? Sau đó, chúng ta phải biến đổi mọi cách thực hiện Class2 ở mọi nơi. Không đẹp mắt lắm, heh? rất có thể là một lần đau đầu rất cao và là một trong những vấn đề thứ nhất trong thiết kế.

Dưới đấy là ví dụ bằng code:

public class ClassA private boolean attributeA; public int methodA() if(attributeA) return new ClassB().attributeB; return -1; public String getValue() return new ClassB().getValue(); public class ClassB public int attributeB; public String getValue() return "Heh?!?";

MỘT SỐ GIẢI PHÁP

LAW OF DEMETER (DON’T TALK to lớn STRANGERS!)

Lợi điểm của Law of Demeter là nó giúp khối hệ thống của bọn họ đứng vững vàng trước phần đông thay đổi bằng cách giảm coupling hay có cách gọi khác là cách design loose coupling, phần lớn sự đổi khác sẽ là nhỏ dại nhất nếu gồm thể.

COHESION

Còn high cohesion (trái ngược với nó là low cohesion) là gì? Khi kể đến cohesion bọn họ nghĩ đến nhiệm vụ của từng module. Trách nhiệm của từng module càng ví dụ và tách bóc biệt thì cohesion càng tốt (high cohesion), cùng đó là phương châm cần đạt tới mức khi thiết kế. Giải thích bằng code chắc rằng sẽ ko rõ ràng, hãy xem xét câu dưới đây:

Tại kỳ họp Quốc hội sản phẩm năm, khi đàm đạo về làm chủ chất lượng vệ sinh an ninh thực phẩm gồm vị đại biểu qh đã ví bài toán có tới 5 bộ chịu trách nhiệm chính như vậy cũng như “nhiều sãi không ai đóng cửa chùa”.Bởi thế, làm rõ trách nhiệm của từng cơ quan thống trị Nhà nước về an ninh thực phẩm là một yêu cầu được nhấn mạnh vấn đề khi kiến thiết Dự Luật an toàn thực phẩm.

Nếu xem Dự Luật an toàn thực phẩm là một trong feature thì rõ ràng nó đang không đạt được tính high cohesion trong xây cất vì nó phải giàn trải và nhờ vào vào tương đối nhiều module (5 bộ, chống ban) khác nhau. Vày đó, khi nên chỉnh sửa bổ sung dự luật sẽ tương đối khó khăn vì buộc phải sửa 1 thời gian 5 module, mà bạn thấy đó, điều đó ví dụ là khôn cùng khó. Trường hợp quy trọng trách xây dựng bộ chính sách này cho một cỗ ban duy nhất thì sẽ sút tính phức tạp và bởi đó, tăng tính cohesion. High cohesion thường đạt được nếu ta vâng lệnh theo nguyên tắc đối kháng nhiệm (Single responsibility principle), từng module, lúc đó chỉ đảm nhiệm một nhiệm vụ duy nhất, không rộng không kém, và không có chuyện 2 module cùng làm cho một nhiệm vụ, một tính năng.

Xem thêm: Sửa Lỗi Runtime Broker Là Gì Và Tại Sao Nó Lại Chạy Trên Pc Của Tôi?

Đến trên đây chắc ai cũng hiểu được rồi đúng không? Ít nhất là về khía cạnh lý thuyết, hãy xem xét bảng sau trước lúc mình đi vào những dẫn giải tiếp theo.