Różnica między skojarzeniem a zależnością?

Jaka jest różnica między relacją skojarzenia a relacją zależności na diagramie klas UML?

Z tego, co wiem, skojarzenie to silniejszy związek niż zależność, ale nie jestem pewien, dlaczego jest silniejszy.

Każdy przykład byłby więcej niż mile widziany :)

Jaka jest różnica między zależnością a skojarzeniem? :

Ogólnie rzecz biorąc, asocjacji używa się do reprezentowania czegoś w rodzaju pola w klasie. Link jest zawsze dostępny, dzięki czemu zawsze możesz poprosić o zamówienie swojego klienta. W rzeczywistości nie musi to być pole, jeśli modelujesz z perspektywy bardziej interfejsu, może po prostu wskazywać na obecność metody, która zwróci klienta zamówienia.

Cytując z 3. edycji UML Distilled (teraz dopiero co) „istnieje zależność między dwoma elementami, jeśli zmiana definicji jednego elementu (dostawcy) może spowodować zmiany w drugim (klient)”. Jest to bardzo niejasna i ogólna zależność, dlatego w UML jest wiele stereotypów dotyczących różnych form zależności. W kategoriach kodu, takie rzeczy, jak nazwanie typu parametru i utworzenie obiektu w zmiennej tymczasowej, implikują zależność.

...

Stowarzyszenie prawie zawsze oznacza, że jeden przedmiot ma inny obiekt jako pole / nieruchomość / atrybutu (zmienne terminologia).

Zależność zwykle (lecz nie zawsze) oznacza, że przedmiot przyjmuje inny obiekt jako parametr sposobu, wystąpienie lub korzysta z innego obiektu. Zależność jest bardzo dużo do zrozumienia przez stowarzyszenie .

W kategoriach OOP:

Skojarzenie -> A ma obiekt C (jako zmienna składowa)

Zależność -> A odwołuje się do B (jako parametr metody lub typ zwracany)

public class A {
    private C c;
    public void myMethod(B b) {
        b.callMethod();
    }
}

Jest też bardziej szczegółowa odpowiedź .

Zależność jest taka, jak w przypadku definiowania metody, która przyjmuje String (w języku Java, C #, ponieważ ciąg jest w nich obiektem) jako parametr, a Twoja klasa jest zależna od klasy String.

Skojarzenie jest podobne do deklarowania ciągu znaków jako atrybutu w klasie. wtedy twój kod jest powiązany z klasą string.

String name = null //: is a association.

Zależność - zmiana w klasie wpływa na zmianę w klasie zależnej. Przykład - Okrąg jest zależny od kształtu (interfejsu). Jeśli zmienisz Shape, wpłynie to również na Circle. Zatem Circle jest zależny od Shape.

Skojarzenie - oznacza, że ​​istnieje pewien związek między 2 obiektami

(jeden-jeden, jeden-wiele, wiele-wiele)

Skojarzenie jest dwojakiego rodzaju-

1. Kompozycja

2. Zbiór

   1) Kompozycja - silniejsze skojarzenie lub związek między 2 obiektami. Tworzysz obiekt klasy B wewnątrz innej klasy A.

 public class A {
       B b;
       public void setB(){
         this.b= new B();
        }
     }

Jeśli usuniemy klasę A, B nie będzie istnieć (obiekt B jest tworzony tylko wewnątrz A).

Inny przykład - Ciało i wątroba. Wątroba nie może istnieć poza ciałem.

2) Agregacja - słabszy typ asocjacji między 2 obiektami.

public class A {       
             B b;
             public void setB(B b_ref){
                 this.b= b_ref;   
                /* object B is passed as an argument of a method */
              }
   }

Nawet jeśli usuniesz klasę A, B będzie istnieć na zewnątrz (B jest tworzony na zewnątrz i przekazywany do klasy A)

Inny przykład - Man & Car. Człowiek ma samochód, ale człowiek i samochód istnieją niezależnie.

Tutaj: „Asocjacja a zależność a agregacja a kompozycja” - masz świetny vade mecum z diagramami klas uml i fragmentami kodu. Autor podaje nam listę relacji: skojarzenie, zależność, agregacja, skład w jednym miejscu.

Zależność jest bardzo ogólna, a zmniejszenie złożoności polega na maksymalnym zmniejszaniu zależności.

Powiązanie jest silną (statyczną) zależnością. Agregacja i kompozycja są jeszcze silniejsze.

Skojarzenie ma miejsce, gdy jeden obiekt ma łącze do innego i nie używa metod obiektów relacyjnych. Na przykład dla rubinu

class User
  has_one :profile
end

user = User.first
profile = user.profile
profile.sign_out

Oznacza to, że możesz pobrać obiekt profilu od użytkownika, ale użytkownik nie używa w sobie metod profilu (nie ma zależności od interfejsu profilu).

Zależność oznacza, że ​​użytkownik ma łącze do innego obiektu i wywołuje w sobie metody tego obiektu

class User
  has_one :profile

  def personal_info
    profile.info
  end
end

Tutaj, jeśli metoda informacji profilu zostanie zmieniona lub zostanie zmieniona nazwa, nasza klasa zależnego użytkownika również musi zostać zmieniona.