Na obrazku klasa Repository jest dla klasy Server?

Poprawna odpowiedź: D

Uzasadnienie i szersze wyjaśnienie:

Przedstawiony diagram UML ilustruje jeden z kluczowych wzorców projektowych – Wstrzykiwanie zależności (Dependency Injection), który jest realizacją zasady odwracania zależności.

1. Klasa Server nie tworzy sama instancji repozytorium. Zamiast tego, otrzymuje ją z zewnątrz poprzez swój konstruktor: Server(repository: Repository).
2. Co ważniejsze, klasa Server nie zależy od konkretnej implementacji repozytorium (takiej jak RepositoryImpl czy RepositoryMock), ale od interfejsu (<<interface>> Repository).

Takie podejście, w którym klasa zależy od abstrakcji (interfejsu), a konkretna implementacja jest dostarczana („wstrzykiwana”) z zewnątrz, nazywane jest luźnym powiązaniem (loose coupling) lub właśnie zależnością miękką. Pozwala to na dużą elastyczność – w zależności od potrzeb można podać klasie Server różne implementacje repozytorium (np. prawdziwą implementację w środowisku produkcyjnym i atrapę RepositoryMock w testach jednostkowych) bez potrzeby modyfikowania kodu samej klasy Server.

Dlaczego pozostałe odpowiedzi są nieprawidłowe?

• A. Zależnością twardą (tight coupling): Byłaby to sytuacja, w której klasa Server sama tworzyłaby konkretną instancję, np. repository = new RepositoryImpl();. Wtedy byłaby na stałe związana z tą jedną, konkretną implementacją.
• C. Klasą pochodną: Na diagramie nie ma relacji dziedziczenia między klasą Server a Repository. RepositoryImpl i RepositoryMock to klasy implementujące interfejs Repository, ale Server nie jest w tej relacji.