Analiza i modelowanie systemów informatycznych z wykorzystaniem notacji UML2 (październik 2016)

Mamy następujący model klas UML: nadklasa Kontrahent i jej dwie podklasy: Klient i Dostawca. Chcemy, aby jeden kontrahent mógł pełnić jednocześnie rolę dostawcy i klienta. Jeden z uczestników długo się wykłócał, uważając że można mieć ten sam obiekt w zależności od potrzeby raz jako obiekt klasy Klient, a raz jako obiekt klasy Dostawca. Twierdził, że z jednego wiersza z tabeli kontrahentów może odczytać obiekt klasy Klient lub obiekt klasy Dostawca, lub nawet oba na raz.

„Zapewne da się w kodzie utworzyć z wiersza tabeli bazodanowej obiekt klasy Klient lub Dostawca, ale jest to łamanie zasad obiektowości. Zgodnie z zasadami obiektowości, obiekt jest zawsze obiektem jednej klasy (nie dwóch na raz). Co więcej, obiekt nie może zmienić tożsamości. Jeśli raz utworzymy obiekt klasy Klient, to nie może on stać się obiektem klasy Dostawca.
< / br>
< / br>
Zatem jeśli wymagamy, aby kontrahent mógł występować jednocześnie w roli klienta i dostawcy, to model, w którym Klient i Dostawca są podklasami Kontrahenta, nie jest właściwy. Role klienta i dostawcy najlepiej jest zamodelować jako związki klasy Kontrahent np. z klasami Towar (kupowany przez klienta) i Surowiec (dostarczany przez dostawcę).”