Wpis z mikrobloga

@UlfNitjsefni: no ale UML to obrazki? co tu konstruować? Dziedzicząca wskazuje na dziedziczoną i tyle.

A tak w ogóle to klasy Pracownik i Klient dziedziczący po Osoba to zły pomysł :) Jak zapiszesz, że ktoś był kiedyś klientem, potem zatrudnił się w firmie, potem znowu coś kupił będąc tu zatrudniony, a potem zmienił stanowisko 2 razy?
@UlfNitjsefni: oj, w sumie zignoruj to co napisałem, wymądrzałem się. Pewnie nie masz w wymaganiach, żeby obsługiwać zmianę stanowisk, dane historyczne, i jednoczesne bycie klientem i pracownikiem.

Jakbyś chciał to wszystko obsłużyć, to obiektowe programowanie się średnio nadaje - lepiej po prostu zrobić tabelki na bazie danych z datą początku i końca trwania danej relacji i rodzajami relacji klient/magazynier/obsługa/prezes i tak dalej.

Ale jak to ćwiczenie do szkoły, to rób tak,
@tell_me_more: nom do szkoły oczywiście, skoro się znasz trochę, to powiedz mi jak określiłem te klasy, to potem żeby opisać jakieś relacje między nimi, to mam do tego stworzyć oddzielną klasę, w której będą znajdować się operację, kupuje produkt, zwraca produkt?
@UlfNitjsefni: możesz, albo możesz zrobić pola w jednej klasie będące wskaźnikami do drugiej klasy. Zależy, jakie są relacje (1:1, 1:N, N:M).

Relację 1:1 można obsłużyć bez dodatkowej klasy - np Mąż może mieć wskaźnik na Żonę albo Żona na Męża i z głowy. Dla szybszego poszukiwania w obie strony (mając męża znajdź żonę i mając żonę znajdź męża) można dodać wskaźnik na partnera w obu klasach.

Relacja 1:N też da się