"Objects should not have PUBLIC's field, you should encapsulate the field with getter / setter." We are too familiar with this rule, familiar with it, completely forgetting it. Uncle Bob puts forward a question: Does the DTO for transmitting data need getter / setter? In fact, in many times, DTO is not an "object" (we use this word "data and behavior of the combination"), just a "data structure" - bringing data from one place to another. Give the "data structure" plus getter / setter, from the OOD angle.
But I have at least two reasons to refute uncle bob. First, sometimes the DTO is to combine or transform data in which the data is carried, gives the form of the UI layer, which requires getter (even setter) package; second, easy to use Jakarta-Commons-BeanUtils tools Provides copy properties between the Java Bean language (ie, getter / setter).
Uncle Bob's Software Craftsmanship Corner
Oh no! DTO!
By Robert C. Martin
February 26, 2004
Summary
SHOULD DTOS HAVE PUBLIC VARIABLES? OR SHOULD THEY HAVE PRIVATE VARIABLES with GETTERS AND SETS?
I'm teaching an XP Immersion (TM) class this week. We are writing FitNesse tests as the acceptance tests for the application we are writing. One of the programmers was using a RowFixture. RowFixture requires the use of a DTO (Data Transfer Object And INSISTS That The Variables Be public. The Programmer Was Aghast. "DTOS Are Always Made with setters!" HE SAID. "Why?" i asseked.
Why indeed? Has the religion of OO carried us so far away from common sense that we can not recognize a data structure when we see one? Why do we need to bloat our code with a bunch of useless getters and setters just to fulfill some Dogmatic Rule That NoBody CAN ADEQUATELY EXPLAIN?
