Klasa Faktura i jej metody

Witam.
Piszę prosty program do faktur. Jednak chciałbym się poradzić co do zgodności kodu z zasadami SOLID.
Przykładowy kod:

 
interface IFaktura {
string Tytul {get;set}
(...)
}

interface IFakturaOperacje {
void dodajPozycje(PozycjaFaktury p);
void usunPozycje(PozycjaFaktury p);
}

class PozycjaFaktury
{
 public string Nazwa {get;set}
 public Decimal Cena {get;set}
 (...)
}
 
class Faktura: IFaktura, IFakturaOperacje
{
 public string Tytul {get;set}
 (...)
 public List<PozycjaFaktury> pozycje {get;set;}
}

Teraz pytanie:
Czy dobrze robię rozdzielając operacje na fakturze w ten sposób? Na początku chciałem zrobić wszystko w klasie faktura, ale wydaje mi się, że można wymyślić to lepiej . Co o tym sądzicie ?

Calosc wydaje sie bez sensu. Faktura dziedziczaca po IFaktura? W jakim celu?
Opisz najpierw dobrze model biznesowy i co wlasciwie chcesz osiagnac?
Po co ci abstrakcja na dodawanie i usuwanie pozycji?

I czemu piszesz w Javie, a zadajesz pytanie w dziale C#?

Piszę w C# .
Chcę to rodzielić np. po to, żeby kolega, który pisze obok drukowanie faktur miał przez gateway dostęp tylko do IFaktura, bo do drukowania nie potrzebne mu są funkcje dodajPozycje, tak samo z raportowaniem i innymi rzeczami, które wymagają tylko odczytu .

Wtedy dla kolegi robię funkcję:

List<IFaktura> SQLGW.PobierzFaktury();

Czemu piszecie, że to złe rozwiązanie ?

Co z tego ze nie korzysta z tych metod? Ale korzysta z obiektu.
Jezeli nie chcesz zeby mial dostep do calego obiektu to przekaz mu wymagane do wydruku dane przez obiekt DTO.

Przyznam się, że pierwszy raz usłyszałem o DTO ;)
Czyli proponujecie, żeby dać sobie spokój z interfejsami, tylko zrobić po prostu klasę Faktura, która ma wszystkie dane i metody typu dodajPozycje ?

Jeszcze dodam, że czytając o tym DTO, nie wiem, w czym jest ono lepsze od zwykłej struktury danych, którą gdzieś komuś możemy przesłać. Osobiście nie lubię takich "windows only" rozwiązań...

wtf, jakie windows only, skad ty to wziales?
http://en.wikipedia.org/wiki/Data_transfer_object

Masz rację. Obczytałem się tylko na stronkach MSDN i takie jakieś dziwne wnioski wyciągnąłem. Czyli konkluzja jest taka, że się to niczym od struktury danych zwykłej nie różni.
Ale do rzeczy. Co z tą klasą Faktura - czy może być tak jak napisałem dwa posty wyżej, że wszystkie metody i dane w jednej klasie ???

To czy wszystkie metody powinny byc w tej klasie zalezy czy nie zlamiesz w ten sposob zasady SRP. Natomiast te metody, ktore podales w pierwszym poscie dotycza agregatu Faktura, sa wiec czescia modelu i powinny byc skladowymi tej klasy.

Dzięki serdeczne.

M napisał(a):

Piszę w C# .

Jak się pisze w C#, to się stosuje konwencje z C#, a nie Javy. Konkretnie o zaczynanie nazw metod wielką literą mi chodzi.

Czemu piszecie, że to złe rozwiązanie ?

Bo z intefejsami nie chodzi o to, żeby je mieć, lecz o to, żeby je mieć tam, gdzie są potrzebne. W tym przypadku, poza skomplikowaniem struktury nic nie dają.

M napisał(a):

Osobiście nie lubię takich "windows only" rozwiązań...

Windows only Martin Fowler: http://martinfowler.com/eaaCatalog/dataTransferObject.html

M napisał(a):

Czyli konkluzja jest taka, że się to niczym od struktury danych zwykłej nie różni.

Różni się i to znacznie, głównie tym, że nie jest strukturą i nie ma z nimi nic wspólnego.

Kurcze - jaka to różnica w czym piszę? Sedno problemu jest wszędzie identyczne, i o ten problem pytałem, ale jak zwykle - 10 postów o tym, że coś jest z małej litery, a 1 post z normalną odpowiedzią. Masakra.
Dzięki za linka do książki - muszę przeczytać, ale wstępnie widzę, że również idea "przekazywania obiektów DTO" jest taka sama jak przekazywania struktur czyli odseparowanie dwóch rożnych rzeczy od siebie. Także "nie ma z nimi nic wspólnego" jest grubą przesadą.
Pozdrawiam.

Ja tylko dodam, że jeśli zamierzasz składować te faktury w pliku, to lepiej jeśli wyklikasz sobie odpowiednie tabele np. w Sql serverze (lub lokalnym pliku bazy) i zaimportujesz całość Entity Frameworkiem. On sam Ci wygeneruje odpowiednie klasy i odpowiednio je rozszerzysz.

M napisał(a):

Kurcze - jaka to różnica w czym piszę? Sedno problemu jest wszędzie identyczne, i o ten problem pytałem, ale jak zwykle - 10 postów o tym, że coś jest z małej litery, a 1 post z normalną odpowiedzią. Masakra.

Zakładam, że jeśli ktoś o coś pyta na forum, to dlatego, że chce coś zrobić dobrze, a nie byle jak. Nietrzymanie się konwencji języka to właśnie przykład bylejakości.

Dzięki za linka do książki - muszę przeczytać, ale wstępnie widzę, że również idea "przekazywania obiektów DTO" jest taka sama jak przekazywania struktur czyli odseparowanie dwóch rożnych rzeczy od siebie. Także "nie ma z nimi nic wspólnego" jest grubą przesadą.

DTO to obiekt klasy, który zawiera jedynie wartości prostych typów, jest łatwo serializowalny i służy do przekazywania z jednej warstwy do drugiej.
Struktura to obiekt wartościowy (a więc alokowany na stosie), który grupuje powiązane ze sobą wartości, a jego rozmiar nie powinien przekraczać 16 bajtów. Przykładem zastosowania mogą być: liczba całkowita, data, punkt w przestrzeni, kolor.
Gdzie widzisz podobieństwo?

Dzięki za opisanie czym jest klasa a czym struktura :|
Jeszcze raz powiem - że obojętnie czego w tym przypadku użyjesz, używasz tego w jednym i tym samym celu. I o to mi generalnie tu chodzi. Dyskusja o tym czy lepiej przekazać struct czy class to naprawdę INNY TEMAT.
Jeśli zadaje pytanie na forum: "Czy dobrze robię rozdzielając operacje na fakturze w ten sposób?", oczekuję odpowiedzi na TO pytanie(tak dobrze, źle, ponieważ...), a nie odpowiedzi, że użyłem złej konwencji. Idąc tą drogą może mi powiesz, że nie mam pola VAT w pozycji, albo że faktura powinna jednak mieć coś więcej niż tylko tytuł, no i że mogę przecież nie używać Listy tylko czegoś prostszego. Ehh.

M napisał(a):

Dzięki za opisanie czym jest klasa a czym struktura :|
Jeszcze raz powiem - że obojętnie czego w tym przypadku użyjesz, używasz tego w jednym i tym samym celu. I o to mi generalnie tu chodzi. Dyskusja o tym czy lepiej przekazać struct czy class to naprawdę INNY TEMAT.

Czytaj dokładnie i ze zrozumieniem. Struktur używa się W ZUPEŁNIE INNYCH celach niż DTO. DTO to klasa o określonym przeznaczeniu. Struktura to twór z zupełnie innej bajki. Jeśli twierdzisz, że jedno jedno można zastąpić drugim, to znaczy, że nie masz pojęcia o tym, czym są struktury.

Jeśli zadaje pytanie na forum: "Czy dobrze robię rozdzielając operacje na fakturze w ten sposób?", oczekuję odpowiedzi na TO pytanie(tak dobrze, źle, ponieważ...), a nie odpowiedzi, że użyłem złej konwencji.

Zawsze się tak spinasz, gdy ktoś Ci zwraca uwagę?

Tak. Zawsze się tak spinam, jeśli pytam o konkretną rzecz, a dostaję odpowiedź na totalnie inny temat.