W moich latach programowania często tworzyłem klasy, które po prostu grupują kilka zmiennych z ich ustawiaczami i pobierającymi. Widziałem te typy obiektów, nazywane obiektami wartości, obiektami domeny lub obiektami modelu w zależności od kontekstu, w którym są używane. Najodpowiedniejszym terminem dla ogólnego użycia wydaje się Data Transfer Object (DTO). Opisuje POJO, który zawiera tylko akcesory i mutatory.Pola publiczne w obiekcie przenoszenia danych
Właśnie napisałem jeden taki obiekt, który zawiera około pięćdziesiąt pól używanych do ustawienia parametrów kompozycji na wykresie. Teraz zastanawiam się, czy zamiast generować setki pobierających i ustawiających powinienem zadeklarować te pola jako publiczne. Takie postępowanie jest sprzeczne z tym, co mówią mi moje instynkty programowania, ale nie mogę zaprzeczyć, że znacznie zwiększyłoby to czytelność mojego kodu i zmniejszyło ilość kodu standardowego w klasie.
Jedyny powód, dla którego mogę zobaczyć nie używać pól publicznych byłoby, gdybym musiał wykonać jakiegokolwiek rodzaju sprawdzania poprawności na tych polach. Jeśli założymy, że walidacja typu jest wystarczająca dla moich celów, to w tym scenariuszu używa pól publicznych akceptowalnej przerwy od projektowania obiektowego? Czy publiczny DTO będzie działał lepiej w dużych operacjach wsadowych?
Możliwy duplikat - http://stackoverflow.com/questions/1568091/why-use-getters-and-setters – sanbhat
pobierające i ustawiające jeżeli są wymagane próbujesz użyć frameworków 'DI' takich jak' Spring' lub coś w stylu 'jsp: useBean' etc !!! – NINCOMPOOP
@sanbhat: niektóre z powodów podanych w zaakceptowanej odpowiedzi na to pytanie mają zastosowanie tutaj, ale nie wszystkie. Zakres i zachowanie DTO różni się od ogólnej klasy, więc zastanawiałem się, czy zastosowalibyśmy tu różne "zasady". – Lilienthal