Bài viết được sự cho phép của Edward Thiên Hoàng
Low coupling và high cohesion là 2 thuộc tính đi cùng với nhau như là mục tiêu cần đạt được trong thiết kế, trong bài viết này, cùng tìm hiểu xem chúng là gì, làm sao để đạt được và tránh các lỗi liên quan đến coupling và cohesion khi thiết kế phần mềm.
COUPLING
Low coupling, loose 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 căn bản đều biết về khái niệm coupling này. Coupling đề cập đến vấn đề phụ thuộc lẫn nhau giữa các component. Low coupling, loose coupling có nghĩa là các component ít phụ thuộc vào nhau, sự thay đổi trong component này ít khi, hoặc không ảnh hưởng đến component kia. Ngược lại, high coupling và tight coupling cho thấy các component phụ thuộc nhiều vào nhau, khi thay đổi 1 component thì các component kia đều bị ảnh hưởng và có khả năng phải thay đổi theo. Tất nhiên, low coupling là mục tiêu chúng ta cần hướng đến để đảm bảo cho hệ thống ít bị ảnh hưởng khi có thay đổi và do đó, tăng tốc độ thực hiện công việc và bảo trì.
Thêm một ví dụ nữa về coupling
Trong câu hỏi trên StackOverflow có một câu trả lời cho thấy một mô tả hài hước nhưng khá chính xác và rõ ràng về những gì 1: 1 coupling là:
iPod là một ví dụ tốt về tight coupling: một khi pin chết bạn cũng có thể mua một chiếc iPod mới vì pin được hàn cố định và sẽ không bị lỏng, do đó thay thế rất tốn kém. Một cái máy có tính loosely coupled sẽ cho phép thay đổi pin dễ dàng.
iPods are a good example of tight coupling: once the battery dies you might as well buy a new iPod because the battery is soldered fixed and won’t come loose, thus making replacing very expensive. A loosely coupled player would allow effortlessly changing the battery.
Tương tự, 1: 1, trong phát triển phần mềm.
Chúng ta sẽ xem xét diagram dưới đây:
Nếu chúng ta nhìn vào hình trên, nó cho chúng ta thấy một mối liên hệ giữa hai class được gọi là tight coupling. Class1 ở trên tạo ra các đối tượng của Class2 trực tiếp, và thậm chí là đi đến các biến thành viên và truy cập vào. Điều này làm cho nó rất phụ thuộc 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ố thêm vào trong constructor của Class2 và đặt mặc định là private? Sau đó, chúng ta phải thay đổi mọi cách sử dụng Class2 ở mọi nơi. Không đẹp lắm, heh? Có thể là một cơn đau đầu rất lớn và là một trong những vấn đề đầu tiên 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
DEPENDENCY INVERSION
Ví dụ trong Java, ta sẽ thêm một interface. Đó là cách Class1 sẽ chỉ phụ thuộc vào interface đó, chứ không phải là implementation thực tế của Class2, do đó giảm thiểu sự phụ thuộc trực tiếp giữa 2 class với nhau.
LAW OF DEMETER (DON’T TALK TO STRANGERS!)
Lợi điểm của Law of Demeter là nó giúp hệ thống của chúng ta đứng vững trước những thay đổi bằng cách giảm coupling hay còn gọi là cách design loose coupling, mọi sự thay đổi sẽ là nhỏ nhất nếu có thể.
COHESION
Còn high cohesion (trái ngược với nó là low cohesion) là gì? Khi nói đến cohesion chúng ta nghĩ đến nhiệm vụ của từng module. Nhiệm vụ của từng module càng rõ ràng và tách biệt thì cohesion càng cao (high cohesion), và đó là mục tiêu cần đạt tới khi thiết kế. Giải thích bằng code có lẽ sẽ không rõ ràng, hãy xem xét câu dưới đây:
Tại kỳ họp Quốc hội thứ năm, khi thảo luận về quản lý chất lượng vệ sinh an toàn thực phẩm có vị đại biểu Quốc hội đã ví việc có tới 5 bộ chịu trách nhiệm chính như vậy cũng giố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 quản lý Nhà nước về an toàn thực phẩm là một yêu cầu được nhấn mạnh khi xây dựng Dự Luật An toàn thực phẩm.
Nguồn: http://vneconomy.vn/thoi-su/an-toan-thuc-pham-bo-nao-trang-trai-bo-nao-ban-an-20100519102635734.htm
Nếu xem Dự Luật An toàn thực phẩm là một feature thì rõ ràng nó đã không đạt được tính high cohesion trong thiết kế vì nó phải dàn trải và phụ thuộc vào rất nhiều module (5 bộ, phòng ban) khác nhau. Do đó, khi cần chỉnh sửa bổ sung dự luật sẽ rất khó khăn vì phải sửa 1 lúc 5 module, mà bạn thấy đó, điều đó rõ ràng là rất khó. Nếu quy trách nhiệm xây dựng bộ luật này cho một bộ ban duy nhất thì sẽ giảm tính phức tạp và do đó, tăng tính cohesion. High cohesion thường đạt được nếu ta tuân thủ theo nguyên tắc đơn nhiệm (Single responsibility principle), mỗi module, khi đó chỉ đảm nhiệm một nhiệm vụ duy nhất, không hơn không kém, và không có chuyện 2 module cùng làm một nhiệm vụ, một tính năng.
Đến đây chắc ai cũng hiểu được rồi đúng không? Ít nhất là về mặt lý thuyết, hãy xem xét bảng sau trước khi mình đi vào các dẫn giải tiếp theo.
Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com
Có thể bạn quan tâm:
- Sự phát triển của các ngôn ngữ lập trình
- Higher Order Functions trong Scala
- Giới thiệu Higher-Order Component trong React
Xem thêm Việc làm Developer hấp dẫn trên TopDev
