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
.