Zrozumienie luźnego / ciasnego łączenia w „prawdziwym świecie”

Nie powiem, co to jest „społeczność”, ponieważ chcę bezstronnego wyjaśnienia, ale powiedzmy, że budujesz moduł wielokrotnego użytku , a moduł ten wymaga modułów zależnych od 3+, a usunięcie 1 z nich powoduje błąd zerwania nie tylko w Twojej aplikacji jako całość, która korzysta z tego modułu, ale sam moduł.

Z mojego zrozumienia (co musi być błędne) luźno połączony system modułowy nie pęknie po prostu usuwając jeden moduł. Aplikacja powinna nadal działać, ale bez tej „funkcji” / modułu, a sam moduł nie powinien powodować, że wszystko nie działa po prostu dlatego, że moduł zależny nie istnieje.

Czy to źle? Jeśli tak, to czy moduły nadal zależą od punktu, w którym wszystko nie działa, jaka jest różnica między szczelnym / luźnym sprzężeniem?

Niezupełnie --- usunięcie modułu może zepsuć system. Idea luźno sprzężonych systemów polega na tym, że zamiana zupełnie innego modułu będzie działać dobrze, o ile nowy moduł będzie spełniał te same wymagania dotyczące interfejsu co stary. Gdyby był ściśle połączony, otaczający kod przyjmowałby domniemania dotyczące elementów wewnętrznych i zacząłby się zawodzić, gdyby wprowadzono nowy moduł.

Luźne sprzężenie jest zasadniczo pośrednią zależnością między modułem od tego, jak mogą ewoluować.

Zasadniczo, gdy istnieją ściśle powiązane systemy, różne moduły / obiekty mają bardzo specyficzne zachowania, które zakładają takie zachowanie obiektów peryferyjnych. Takie obiekty są powiązane / sprzężone z innymi zachowaniami modułów i nie można ich ponownie użyć w oderwaniu ani w żadnym innym kontekście.

Takie moduły, mimo że odpowiedzialne za poszczególne funkcje, nie mogą ewoluować niezależnie lub nie mogą ewoluować

Przykład:

Załóżmy, że masz 3 obiekty Shape(obiekt modelu) i Canvas(element interfejsu użytkownika). Teraz

Załóżmy, że metoda shape.draw(Canvas)narysuje obiekt na płaszczyźnie dostarczonej przez płaszczyznę płótna.

Teraz czasami okna są częściowo zakrywane i zmieniane są ich rozmiary. W takich przypadkach powyższa metoda może po prostu zrobić coś takiego.

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. 
}

Zasadniczo tutaj funkcja rysowania podnosi prostokąt, w którym należy rysować. Jest to łatwy do zrozumienia (ludzie mogą nazwać ten prosty ) kod. Jest to jednak bardzo sprzężony kod.

Wyobraź sobie sytuację:

• Co jeśli mechanizm utrzymywania okien w obszarze roboczym nie jest już prostokątem?
• co jeśli istnieją dodatkowe przesunięcia, które Canvas zachowuje, co jest prywatne ?
• Co jeśli inna aplikacja chce mieć ten sam kształt, ale nie ma już okna GUI (na przykład tworzy obrazy i zapisuje w plikach).

Przyczyną tego problemu jest to, że przedmiot shape nie wie , a tym samym szczelnie sprzężony z Canvas.

Co jest pożądane, aby zestaw pikseli został nadany kształtowi w miejscu, w którym pisze; shapenie powinno mieć (nawet dorozumianą) Wiedza o tym, gdzie piksele są rzeczywiście napisane.

To zależy, nawet od tego, co określisz jako moduł. Niektóre części systemu powinny być ściśle powiązane (na przykład, twoje jednostki powinny być ponownie wykorzystywane w całej aplikacji), ale niektóre systemy powinny być luźne, albo z separacją interfejsów, albo jeśli mówimy o tym, aby nie złamać aplikacji, jeśli usuniesz moduł , to ten moduł musi być podłączony jakoś dynamicznie, może przez kontener IoC lub coś takiego.

Również ścisłe połączenie oznacza, że ​​pewna część zależy od konkretnej implementacji modułu, a nie od definicji modułu czy czegoś takiego.