Rezerwacje dla wypożyczalni kaset - diagram klas

Witam,

chciałbym prosić o wskaznie błędów w poniższym diagramie - podobno się od nich roi, jednak nie wiem, co wykładowca ma na myśli.

Twój wykładowca ma rację.

Nr telefonu: String a nie Integer.
Jak będzie Integer, to zgubisz wiodące zera. Poza tym może nie starczyć zakresu.

Nr klienta: czemu String a nie Integer?
Czemu wypozyczoneFilmy zwraca Boolean?
wyszukajTytul powinno chyba coś zwracać.
Skoro Pracownik i Klient obaj mogą dokonywać rezerwacji, to dokonywanie rezerwacji powinno być wydzielonym interfejsem / klasą bazową.

Dalej nie chce mi się sprawdzać.

Skoro każda osoba ma adres to niech klasa Adres będzie zawarta w klasie Osoba, a najlepiej porzuć klasę Adres i dodaj odpowiednie pola klasie Osoba.

Co to ma do rzeczy, który pracownik zarządza filmami i wypożyczeniami ? Ja bym zmienił tego pracownika na singleton "Wypozyczalnia".

W klasie Film zamieniłbym pole CzyWypozyczony na IloscWypozyczonych i IloscDostepnych.

Relacja Wypozyczalnia<->Film powinna być "jeden do wielu", a nie "jeden do jednego".

A ja sie nie zgodzę z tobą adf88 w kilku miejscach.

1. Dodanie pól klasy Adres do klasy Osoba bardzo psuje jej spójność. Kod pocztowy ulicy na której mieszkam raczej niewiele ma wspólnego ze mną jako osoba. Pyzatym ograniczasz sobie znacznie rozwijanie kodu. A co jeśli będziesz chciał dodać np oprócz adresu zwykłego, także np adres korespondencyjny ? Musiałbyś dodać kilka pól, zamiast jednego. Ograniczasz możliwości ponownego ożycia kodu. Co jeśli chciałbyś użyć klasy Adres w innym miejscu kiedyś ? Musiałbyś z powrotem wyciągać te pola, tworząc klasę, lub powielać je w innym miejscu.
   Wiec jak dla mnie pomysł fatalny.

2. Faktem jest ze funkcjonalność jaka daje 'dodajFilm' 'usunFilm' itd totalnie nie pasują do klasy Pracownik, tylko faktycznie powinna byc do tego klasa zarządzającą filmami (np, tak jak adf88 powiedział Wypożyczalnia). Klasę pracownik bym jednak zostawił, ponieważ na temat pracownika często potrzebujemy wiedzieć więcej niż na temat klienta (np numer NIP czy coś tego typu).

3. Klasa film. Powinna byc rozbita na dwie. Jedna coś typu FilmInfo, która by zawieralaby informacje na temat filmu (tytul, opis, rok produkcji, aktorzy itd). Oraz klasa np FilmInstance, która by reprezentowała konkretny egzemplarz na polce (zawierałaby oczywiście w sobie pole będące typu FilmInfo). Takie rozgraniczenie wydaje mi sie bardziej sensowne, ponieważ ma odzwierciedlenie w świecie rzeczywistym.

ad 1. ten projekt raczej nie będzie rozwijany, no ale ok, tu masz faktycznie racje.
ad 2. nie pisałem, żeby się w ogóle pracownika pozbyć. Można go nawet użyć podczas wypożyczania (kto wypożyczył, kto przyjął)
ad 3. racja, ale jeśli FilmInstance miałaby zawierać jedynie pola 'id' i 'filmInfo' i 'dostepny' to bez sensu.