Khi nào thì khớp nối Efferent / Afferent tốt hay xấu

Tôi có một bài kiểm tra mẫu phần mềm trong tuần này và một trong những chủ đề chúng ta sẽ nghiên cứu là khớp nối Efferent và Afferent.

Tôi hiểu rằng một gói có CE cao (khớp nối hiệu quả) nếu nó phụ thuộc vào một số loại khác.

Ví dụ:

class Car{
    Engine engine;
    Wheel wheel;
    Body body;
}

Lớp này sẽ có khớp nối hiệu quả cao vì nó phụ thuộc vào các loại Động cơ, Bánh xe và Thân xe.

Trong khi đó loại "Bánh xe" sẽ có Ca (khớp nối hướng tâm) cao nếu một số gói khác phụ thuộc vào nó (Xe hơi, Máy bay, Xe đạp).

Một trong những câu hỏi có thể có trong bài kiểm tra của chúng tôi là, khi nào thì khớp nối Efferent / Afferent tốt hay xấu? Điều này có vẻ kỳ lạ đối với tôi bởi vì về mặt logic, một chương trình sẽ cần các gói / lớp với cả khớp nối Efferent / Afferent cao.

Có ai có một ví dụ về thời điểm / nơi khớp nối hiệu quả cao hoặc liên kết tốt là tốt / xấu ??

Cảm ơn !

Khớp nối có thể dễ dàng được đánh giá nhất về mức độ đau / tiết kiệm do sự cần thiết hoặc khả năng thay đổi. Ví dụ, lấy lớp bánh xe của bạn và giả sử rằng nhiều mô-đun khác sử dụng nó để chế tạo các loại phương tiện khác nhau. Nếu lớp bánh xe cực kỳ ổn định, thì khớp nối hướng tâm này có lợi vì các phương tiện cần bánh xe và chúng đang sử dụng loại đáng tin cậy. Mặt khác, nếu lớp bánh xe không ổn định về mặt bảo trì, thì khớp nối hướng tâm này sẽ là một điểm đau khi bạn đưa ra các thay đổi liên tục cho nhiều mã.

Ghép nối Efferent là khái niệm tương tự, nhưng bạn sẽ xem xét một đề xuất giá trị hơi khác nhau. Nếu bạn có một lớp xe hơi phụ thuộc trực tiếp vào rất nhiều bộ phận riêng lẻ (trái ngược với chỉ nói "Động cơ" và "Khung gầm", và chúng bao gồm các bộ phận phụ khác), lớp có thể làm rất nhiều và do đó có thể là một tắc nghẽn bảo trì. Thay đổi đối với lớp đó có thể sẽ khó khăn và rủi ro vì sự phức tạp của nó. Mặt khác, nếu độ khớp nối cao, nhưng thực sự khá gắn kết và rõ ràng, thì bạn không có hệ thống các đối tượng và mối quan hệ phải lo lắng.

Khi nói đến kiến ​​trúc / thiết kế, những gì bạn thực sự phải xem xét là khá nhiều sự đánh đổi vô tận và những số liệu này không khác nhau. Nếu bạn muốn tìm ra một ví dụ về điều gì đó tốt hay xấu, hãy chơi trò chơi "what if". Tưởng tượng một ví dụ và nói "nếu tôi muốn làm X - thì nó sẽ hút bao nhiêu?" Đối với X trong đó câu trả lời là "rất nhiều", bạn có một bất lợi và đối với X trong đó câu trả lời là "điều đó thực sự rất dễ" bạn có một lợi thế.

Nói chung chung, khớp nối lỏng lẻo:

tích cực : bảo vệ một phần của hệ thống khỏi những thay đổi trong một cái gì đó mà nó phụ thuộc vào (khớp nối hướng tâm)

tiêu cực : mối quan hệ có thể khó hiểu hơn

Ví dụ: nếu tôi đang phát triển một hệ thống dựa trên HTTTP, tôi sẽ quyết định xem tôi cần kết hợp chặt chẽ hay lỏng lẻo với HTTP. Nếu tôi nghĩ rằng hệ thống có khả năng chuyển sang một giao thức khác, tôi có thể chọn kết nối lỏng lẻo với nó, trong khi nếu tôi chấp nhận HTTP là giao thức của mình, tôi có thể hiểu rõ giao thức đó để đơn giản.

Hãy xem xét rằng một số sự phức tạp trong WS * đang tách rời khỏi HTTP như một giao thức.

Liên kết

Nếu một cái gì đó sử dụng một loạt các công cụ khác nhau (số lượng lớn các khớp nối hướng tâm), thì nó có thể dễ bị phá vỡ nếu bất kỳ thứ gì trong số đó thay đổi.

_{Sự bất ổn = 1}

Nỗ lực

Nếu một cái gì đó được sử dụng bởi một loạt các công cụ khác nhau (số lượng lớn các khớp nối tràn đầy), thì nó có thể dễ bị phá vỡ nhiều thứ nếu nó thay đổi.

_{Sự bất ổn = 0}

Ổn định

Định nghĩa "ổn định" của Martin là sự pha trộn kỳ lạ giữa "khó thay đổi" và "có vài lý do để thay đổi". Tuy nhiên, số liệu không ổn định của anh ta chỉ mô tả "khó khăn của thay đổi". "Lý do để thay đổi" sẽ liên quan nhiều hơn đến các yếu tố không thể tính toán dễ dàng, như chỉ cần thiết kế giao diện của bạn một cách phù hợp, ở mức độ trừu tượng phù hợp và hiểu rõ hơn các yêu cầu cuối của người dùng.

Vì vậy, khớp nối hiệu quả cao với khớp nối hướng tâm thấp mang lại sự ổn định (như trong một điều gì đó khó thay đổi vì nó sẽ phá vỡ một loạt các thứ), điều ngược lại mang lại sự không ổn định (như trong một thứ dễ thay đổi vì nó sẽ không phá vỡ một loạt các thứ) .

Một số lượng lớn các khớp nối hướng tâm có thể là một dấu hiệu cho thấy thiết kế của bạn thiếu tập trung - đó là sử dụng một loạt các công cụ khác nhau để có thể nó thiếu trách nhiệm rõ ràng, đơn lẻ.

Một số lượng lớn các khớp nối hiệu quả ban đầu có thể được hiểu là một điều thực sự tốt, vì nó chỉ ra rằng thiết kế của bạn đang được sử dụng rộng rãi. Tuy nhiên, điều đó sẽ rất tệ nếu bạn cảm thấy muốn thay đổi thiết kế thường xuyên theo cách phá vỡ mọi thứ. Vì vậy, với một số lượng lớn các khớp nối hiệu quả, cần phải có các gói như vậy có "ít hoặc không có lý do để thay đổi". Các thiết kế nên ổn định theo nghĩa lý tưởng là không có lý do để thay đổi, vì chúng cũng sẽ rất khó thay đổi.

Nguyên tắc trừu tượng ổn định

Các khái niệm như đảo ngược phụ thuộc (mà tự nhiên gọi là tiêm phụ thuộc) và SAP (nguyên tắc trừu tượng ổn định) đều cho thấy rằng phụ thuộc chảy vào trừu tượng. Và có một lý do đơn giản tại sao khi xem xét "sự ổn định" trong bối cảnh có "một vài lý do để thay đổi". Một giao diện trừu tượng đề cập đến không có chi tiết cụ thể, nó chỉ tập trung vào "phải làm gì" thay vì "những gì đang xảy ra", và do đó có ít lý do để thay đổi. Cổng đồ họa được tăng tốc trên bo mạch chủ của chúng tôi (giao diện trừu tượng) có ít lý do hơn để thay đổi thiết kế so với GPU cắm vào nó (một chi tiết cụ thể).

Tái sử dụng so với tái sử dụng

Một loại số liệu cá nhân của riêng tôi nếu tôi có thể đề xuất một số liệu có thể va chạm với Martin là khái niệm này tôi muốn thúc đẩy rằng các thư viện có thể tái sử dụng nhất nên tìm cách sử dụng tối thiểu mã khác. Điều đó đẩy sự bất ổn về phía khó 0. Đó là vì lý do thực tế của việc có lý do tối thiểu để thay đổi, nhưng cũng để thúc đẩy thư viện dễ triển khai nhất. Một thư viện có mục đích chung, được sử dụng rộng rãi, phụ thuộc vào hàng tá thư viện khác nhau có rất nhiều lý do để thay đổi, cũng như phân phối bó lúng túng có thể khó triển khai. Sự khác biệt ở đây là "lý do để thay đổi" trong trường hợp của tôi thậm chí còn mở rộng đến việc thực hiện, vì nó xuất phát từ quan điểm hướng thư viện tìm cách phát hành các phiên bản ổn định của thư viện. Martin có thể giảm giá việc thực hiện như một phần rất riêng biệt,

Từ quan điểm phân phối, triển khai và giao diện mờ cùng nhau để mang lại sự phụ thuộc của người dùng vào một thư viện ổn định hoặc không ổn định. Từ quan điểm giao diện, chỉ giao diện được sử dụng và các chi tiết thực hiện liên quan là hoàn toàn riêng biệt.