Witam!
Chciałbym nauczyć się programowania obiektowego. Dlatego też postanowiłem stworzyć aplikacje (opartą na bazie MSSQL) do zarządzania zamówieniami.
W pierwszej kolejności postanowiłem zająć się zarządzaniem kontrahentami, stworzyłem diagram klas i interfejsów, który zamieszczam w załączniku.
Proszę o weryfikacje i wszelkie sugestie.
Dlaczego klasę nazwałeś CClient, a nie po prostu Client?
Co to za nazwa metody Name? Nazwy metod powinny być czasownikami, nie rzeczownikami.
Interfejsy I*Counterparty - mają one jakiś większy sens?
Do czego ma służyć metoda CClient.AddClient. Wygląda, jakby miało to polegać na dodaniu klienta do klienta. Jaki to ma sens? Bo jeśli chodzi o dodawanie do bazy danych, to powinieneś mieć klasę ClientsRepository i w niej metody do dodawania, usuwania, itp. obiektów klasy Client.
Czemu mają służyć interfejsy IClient i IMandatory? Moim zdaniem nie mają sensu, zwłaszcza w kontekście tego, co napisałem powyżej.
City, Street, PostCode - to raczej właściwości dla klasy Address. Warto rozważyć czy nie warto by takiej wydzielić.
Ograniczenie tylko dla jednego numeru telefonu i adresu email dla klienta może wymagać później poprawy.
W poczet kontrahentów zaliczam klientów i zleceniobiorców, a każdy z nich może byś zarówno osobą fizyczną lub firmą.
Klient i zleceniobiorca mają wspólne właściwości (temu miał służyć interfejs ICounterparty):
ale mają też właściwości zależne od przynależności do grupy (osoba fizyczna IIndyvidual.. lub firma ICorporate..):
W Interfejsach IClient i IMandatory miały znaleźć się metody (operacje na bazie danych) do dodawania, usuwania, itp. obiektów klasy Client i Mandatory oraz do dodawania ich do zamówień (Client.Add, Mandatory.Add, itd.)
Obie Twoje klasy implementują wszystkie trzy interfejsy I*Counterparty, ponadto różnią się jedynie dwiema właściwościami pochodzącymi z interfejsu IMandatory. Nie widzę sensu takiego podejścia - namnożyłeś interfejsów, które nic tu raczej nie wniosą. Planujesz je jakoś wykorzystać w operacjach na tych obiektach?
W takim przypadku jak ten, że dwa typy klientów mają pewne wspólne właściwości lepiej chyba zrobić bazową klasę (abstrakcyjną). Nie widzę tutaj żadnego uzasadnienia dla istnienia interfejsu (chyba, że jest obejściem ułomności jakiejś innej technologii, np. ORMa, który nie wspiera dziedziczenia).
bodzios napisał(a)
- Type (0-osoba fizyczna /1- firma)
W tym miejscu, do zdefiniowania typu przydałby się raczej enum, a nie magiczne liczby.
W Interfejsach IClient i IMandatory miały znaleźć się metody (operacje na bazie danych) do dodawania, usuwania, itp. obiektów klasy Client i Mandatory oraz do dodawania ich do zamówień (Client.Add, Mandatory.Add, itd.)
Klas powinna zajmować się jedną rzeczą. Klasa reprezentująca klienta nie może zajmować się operacjami na bazie danych. Od tego powinna być, jak już pisałem wcześniej, oddzielna klasa-repozytorium. Idąc dalej, jeśli trzeba dodać klienta do zamówienia, to klasa zamówienie powinna mieć metodę Add(Client), a nie odwrotnie. No chyba, że dodajemy zamówienie do klienta, wtedy metoda jest w klasie Client.
Jak już pisałem dopiero zaczynam przygodę z programowaniem obiektowym i stąd moje bezsensowne pomysły.
Pomysł z interfejsem IMandatory wziął się stąd, że: w przypadku Klienta nie muszę zbierać takich informacji jak nr konta w przeciwieństwie do Zleceniobiorcy, któremu muszę zapłacić za wykonaną pracę (sam się teraz zastanawiam jak miałbym to wykorzystać w praktyce).
O klasie abstrakcyjnej nie pomyślałem, a na pewno jest bardziej sensowna
Źle ująłem to co miałem na myśli:
w klasie Client chciałem mieć metodę służącą definiowaniu nowego klienta, a sam zapis w bazie byłby już realizowany wg. Twoich sugestii poprzez klasę repozytorium.
Ja nie mówię, że bezsensowne. Ale im więcej kodu, tym trudniej go potem utrzymać. ;)
bodzios napisał(a)
w klasie Client chciałem mieć metodę służącą definiowaniu nowego klienta
Co konkretnie przez to rozumiesz?
Bo dla mnie definiowanie nowego klienta, to utworzenie nowego obiektu klasy Client, a metodą która do tego służy jest po prostu konstruktor.