Witajcie
próbuję napisać aplikacje do fakturowania i zastanawiam się czy jakiś wzorzec był by przydatny. Myślałem nad tym że taka faktura powinna być kompozytm, czy to dobry pomysł, czy iść raczej w innym kierunku. Nie bardzo wiem jak ogarnąć to, że faktura zawiera towary, jakieś rabaty, koszty dostawy itp i wartosci na tych elementach powinny wpływać na wartości faktury jako całości.
Bardzo proszę o radę jak się zabrać za coś takiego.
0
0
Sama faktura nie powinna mieć logiki dotyczącej rabatów itd. Tylko posiadać te informacje, które należą konkretnie do faktury. Trzymajmy się zasady SRP.
Natomiast serwisy i inne obiekty, które zajmują się przetwarzaniem zamówień, rabatów itd. i w efekcie tworzeniem końcowej faktury powinny posiadać tę logikę.
0
Chdzk napisał(a):
Sama faktura nie powinna mieć logiki dotyczącej rabatów itd. Tylko posiadać te informacje, które należą konkretnie do faktury. Trzymajmy się zasady SRP.
Natomiast serwisy i inne obiekty, które zajmują się przetwarzaniem zamówień, rabatów itd. i w efekcie tworzeniem końcowej faktury powinny posiadać tę logikę.
Jeśli ma trzymać tylko informacje, które należą konkretnie do faktury, to musi właśnie przetrzymywać też informację o rabatach i innych tego typu rzeczach. Może napiszę bzdurę, ale nie jestem przekonany, że np. klasa Faktura nie powinna mieć jakiejś metody "przeliczRabat", ale to już zależy od tego, jak projektujący tę klasę zadecyduje (czy będzie to miał jako integralną część klasy, czy będzie traktował fakturę jak strukturę i miał mechanizm do "obróbki" takich struktur).
0
fourfour napisał(a):
Może napiszę bzdurę, ale nie jestem przekonany, że np. klasa Faktura nie powinna mieć jakiejś metody "przeliczRabat", ale to już zależy od tego, jak projektujący tę klasę zadecyduje (czy będzie to miał jako integralną część klasy, czy będzie traktował fakturę jak strukturę i miał mechanizm do "obróbki" takich struktur).
Liczenie rabatów nie jest odpowiedzialnością faktury, jest odpowiedzialnością modułu rabatowania.
Różni klienci chcą mieć rabatowanie rozwiązane na różne sposoby.
Powinno być więc to łatwe do wyłączenia, podmienienia i rozszerzenia o kolejne sposoby rabatowania.
Faktura się nie zmienia, chyba, że zmieniają się przepisy fiskalne w kraju.
Kiedyś pisałem w jednej firmie dosyć skomplikowany moduł rabatowania do systemu ERP, więc znam problem z autopsji ;)
0
czyli powinienem mieć np jakis service np
class FakturaMenager
{
public Faktura WystawFakture(List<Towar> towary, Rabat rabat)
{
//...
}
// ...
}
oraz zwykłe klasy:
class Faktura
{
List<Towar> towary;
Rabat rabat;
//.....
}
class Towar
{
//...
}
class Rabat
{
//...
}
Czy tak to powinno wyglądać?
0
Chdzk napisał(a):
Kiedyś pisałem w jednej firmie dosyć skomplikowany moduł rabatowania do systemu ERP, więc znam problem z autopsji ;)
No tak, zapomniałem się, przepraszam.
:P
0
@Chdzk taki DoscountService powinien dostawać obiekt Faktura i na podstawie swoich wewnętrznych zasad przeliczać rabat dla całej faktury, ewentualnie dla poszczególnych towarów?
1
DiscountService powinien dostawac to, od czego zalezy wyliczenie rabatu.
Czyli jezeli masz gdzies zapisane rabaty - to powinien miec dostep do repozytorium z tymi rabatami no i do zamawianych pozycji, bo na podstawie tych pozycji jest wyliczany rabat.
Faktura jest tylko efektem koncowym calosci procesu. Architektura powinna byc tak skonstruowana, ze nawet jak ktos nie chce rabatowania, to moze zrezygnowac, a na koncu i tak dostanie fakture dla zamowionych pozycji.