Hiểu về khớp nối lỏng lẻo / chặt chẽ trong thế giới Real Real

Tôi sẽ không nói "cộng đồng" là gì vì tôi muốn một lời giải thích không thiên vị, nhưng giả sử bạn đang xây dựng một mô-đun có thể tái sử dụng và mô-đun đó yêu cầu hơn 3 mô-đun phụ thuộc và loại bỏ 1 trong số chúng gây ra lỗi không chỉ trong ứng dụng của bạn toàn bộ sử dụng mô-đun này, nhưng chính mô-đun.

Theo hiểu biết của tôi (phải sai), một hệ thống mô-đun được ghép lỏng lẻo sẽ không bị hỏng chỉ bằng cách loại bỏ một mô-đun. Ứng dụng vẫn nên chạy nhưng không có "tính năng" / mô-đun đó và chính mô-đun không nên khiến mọi thứ không chạy đơn giản vì mô-đun phụ thuộc không tồn tại.

Điều này có sai không? Nếu vậy, nếu các mô-đun vẫn phụ thuộc vào điểm của mọi thứ không hoạt động thì có gì khác biệt giữa khớp nối chặt / lỏng?

Không hoàn toàn --- loại bỏ mô-đun cũng có thể phá vỡ hệ thống. Ý tưởng đằng sau các hệ thống được ghép lỏng lẻo là việc hoán đổi trong một mô-đun hoàn toàn khác sẽ hoạt động tốt miễn là mô-đun mới tuân thủ các yêu cầu giao diện giống như mô-đun cũ. Nếu nó được kết hợp chặt chẽ, mã xung quanh sẽ đưa ra các giả định về phần bên trong và sẽ bắt đầu thất bại nếu một mô-đun mới được giới thiệu.

Khớp nối lỏng lẻo về cơ bản là sự phụ thuộc gián tiếp giữa các mô-đun vào cách chúng có thể phát triển.

Nói chung, khi có một hệ thống kết hợp chặt chẽ, các mô-đun / đối tượng khác nhau có các hành vi rất cụ thể giả định hành vi đó của các đối tượng ngoại vi. Các đối tượng như vậy được liên kết / kết hợp với các hành vi mô-đun khác và chúng không thể được sử dụng lại trong sự cô lập hoặc trong bất kỳ bối cảnh nào khác.

Các mô-đun như vậy mặc dù chịu trách nhiệm về chức năng cá nhân không thể phát triển độc lập hoặc không thể phát triển

Một ví dụ:

Giả sử bạn có 3 đối tượng Shape(một đối tượng mô hình) và Canvas(một thành phần UI). Hiện nay

Giả sử rằng một phương thức shape.draw(Canvas)sẽ vẽ một đối tượng trên mặt phẳng được cung cấp bởi mặt phẳng của khung vẽ.

Bây giờ, đôi khi các cửa sổ được che một phần và được thay đổi kích thước. Trong những trường hợp như vậy, phương pháp trên có thể chỉ cần làm một cái gì đó như thế này.

shape::draw(Canvas) {
   Rect.WindowLeft = Canvas.GetWindowRect.getLeftOffset(); 
   Rect.LeftPixel = Canvas.GetWindowRect.pixels() + Rect.WindowLeft; 
   ....  // like this get all co-ordinates. 

   draw_instance(Rect);  // This will draw the actual shape. 
}

Về cơ bản, ở đây hàm vẽ sẽ chọn hình chữ nhật nơi mọi thứ cần được vẽ. Điều này là dễ hiểu (mọi người có thể gọi mã này đơn giản ). Tuy nhiên, đây là mã cực kỳ kết hợp.

Hãy tưởng tượng tình huống:

• Điều gì xảy ra nếu cơ chế giữ cửa sổ của canvas không còn là hình chữ nhật?
• Điều gì xảy ra nếu có thêm phần bù mà Canvas giữ ở chế độ riêng tư ?
• Điều gì sẽ xảy ra nếu một số ứng dụng khác muốn có hình dạng tương tự nhưng không còn có cửa sổ GUI (ví dụ: nó đang tạo hình ảnh và lưu trong tệp).

Nguyên nhân sâu xa của vấn đề là đối tượng shape biết và do đó kết hợp chặt chẽ với Canvas.

Điều gì là mong muốn mà một bộ pixel được đưa ra để định hình nơi nó ghi; các shapekhông nên có (thậm chí tiềm ẩn) kiến thức về nơi các điểm ảnh được thực sự bằng văn bản.

Nó phụ thuộc, thậm chí vào những gì bạn chỉ định là mô-đun. Một số phần của hệ thống nên được kết hợp chặt chẽ (ví dụ: các thực thể của bạn nên được sử dụng lại trên toàn bộ ứng dụng), nhưng một số hệ thống sẽ bị lỏng lẻo, với sự phân tách giao diện hoặc nếu chúng ta đang nói về việc không phá vỡ ứng dụng nếu bạn gỡ bỏ mô-đun , sau đó mô-đun đó phải được nối dây một cách linh hoạt, có thể thông qua bộ chứa IoC hoặc một cái gì đó.

Ngoài ra, khớp nối chặt chẽ có nghĩa là một số phần phụ thuộc vào việc thực hiện mô-đun cụ thể , không phải là định nghĩa của mô-đun hoặc một cái gì đó.