DDD i korzystanie z Getters and Setters

Question

Przeczytałem kilka artykułów/postów dotyczących korzystania z Getters i Setters, i jak pomagają one pokonać cel enkapsulacji w obiektach modelu domeny. Rozumiem logikę kryjącą się za używaniem ustawiaczy - pozwalasz kodowi klienta manipulować atrybutami tego obiektu, poza kontekstem reguł biznesowych i niezmienników obiektu.

Teraz ten dyrektor nadal mnie myli. Na przykład, co się stanie, jeśli będę musiał zmienić wartość zmiennej składowej obiektu? Na przykład, jeśli nazwisko osoby zmienia się, w jaki sposób mogę to odzwierciedlić w modelu? Na początku pomyślałem, dlaczego nie mam funkcji o nazwie "ChangeName", która pozwala mi podać nową nazwę, a to z kolei może zmienić wewnętrzną zmienną "name". Cóż ... to tylko seter, prawda!

Co muszę wyjaśnić - jeśli miałbym całkowicie wyeliminować seterów, to czy w sytuacjach takich jak powyższy mam polegać wyłącznie na parametrach konstruktora? Czy powinienem przekazać nową wartość atrybutu w miejsce starej wartości atrybutu za pomocą konstruktora, po czym mogę kontynuować zmiany, przekazując obiekt do jakiejkolwiek infrastruktury trwałości, którą posiadam?

Te dwa artykuły są użyteczne w tej dyskusji:

1. http://kellabyte.com/tag/ddd/
2. http://typicalprogrammer.com/?p=23

Answer 1

Cóż, jest to klasyczny dyskusja. Jest tu jeszcze kilka innych wątków w Stack Overflow.

Ale. Get/Set's (Auto Properties?) Nie są złe. Ale zwykle sprawiają, że konstruujesz swoje istoty jako "martwe" kontenery danych, które mają tylko rekwizyt, a nie metody. Oznaki tego są często nazywane domeną anemiczną - i mają bardzo niewielkie zachowanie. Moje zalecenie to:

1. Staraj się używać podpory tak mało, jak to tylko możliwe.
2. Spróbuj znaleźć grupy danych, które należą do siebie i POWINNY BYĆ razem jak np. Imię Middlename i Nazwisko. Inny przykład: to Kod pocztowy, Miejscowość, Ulica. Te dane można lepiej ustawić za pomocą metody . Minimalizuje szanse na unieważnienie twojego bytu.
3. Często dane, które należą do siebie, można zgrupować jako obiekt o wartości: .
4. Więcej obiektów wartości zwykle wydają się bardziej opisowe metody z Twojej jednostki, które są "Czasowniki" zamiast swoich zwykle "Rzeczowniki" podmiotów.
5. Więcej metod dla twoich wartościowych obiektów także otwiera się na dodawanie więcej zachowania i może zmniejszając twoje "Grube" usługi (być może nie masz usług o zbyt dużej przecieku logice biznesowej ...).

Jest tu więcej do powiedzenia ... ale krótka odpowiedź. O ustawianiu danych w konstruktorze: robię to tylko wtedy, gdy ta jednostka nie może "żyć"/istnieje bez tych danych. Jeśli chodzi o istotę podmiotu, powiedziałbym, że nazwa może nie jest tak ważna. Ale numer ubezpieczenia społecznego może być kandydatem do danych konstruktorów. Lub podmiot Pracownik musi mieć firmę w konstruktorze, po prostu dlatego, że pracownik musi należeć do firmy.