Weblogs Forum - Oh No! DTO!

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Oh No! DTO!

31 replies on 3 pages. Most recent reply: Apr 25, 2007 11:45 PM by Risto Peränen

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 31 replies on 3 pages [ 1 2 3 | » ]

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Oh No! DTO! (View in Weblogs)

Posted: Feb 26, 2004 3:55 PM

Summary
Should DTOs have public variables? Or should they have private variables with getters and setters?

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 private variables and getters and setters!" he said. "Why?" I asked.

Why indeed? Has the religion of OO carried us so far away from common sense that we can't 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?

In my view OO programs contain two kinds of entities: Objects and Data Structures. Objects have private data and public methods. Data Structures have public data and no methods (or sometimes trivial navigational methods). There are very good reasons for keeping the variables in an object private. We want to know which functions can manipulate them. We want to protect the invariants of the object. We don't want others to depend on our details (DIP). On the other hand there is no good reason to use getters and setters in a data structure. A data structure is simply a packet of data, nothing more.

Dave Astels

Posts: 32
Nickname: dastels
Registered: Mar, 2003

Re: Oh No! DTO!

Posted: Feb 26, 2004 6:29 PM

> On the other hand there is no good
> reason to use getters and setters in a data structure. A
> data structure is simply a packet of data, nothing more.

Nice job, Bob.

Sometimes a data structure is just a data structure.

(apologies to Freud)

Dave

Jason Yip

Posts: 31
Nickname: jchyip
Registered: Mar, 2003

Re: Oh No! DTO!

Posted: Feb 27, 2004 12:16 AM

Heh... Never thought of blogging about this so I'm glad you did. Had similar thoughts the first time I saw a getter/setter DTO.

The use of JavaBean introspection by many frameworks and CheckStyle rules make this an annoying battle to fight though...

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Oh No! DTO!

Posted: Feb 27, 2004 1:50 AM

> Heh... Never thought of blogging about this so I'm glad
> you did. Had similar thoughts the first time I saw a
> getter/setter DTO.
>
> The use of JavaBean introspection by many frameworks and
> CheckStyle rules make this an annoying battle to fight
> though...

Bjarne Stroustrup made the same point in the first installment of his interview:

http://www.artima.com/intv/goldilocks2.html

He said:

I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn't have been a class in the first place. It's just a data structure. And if it really is a data structure, make it a data structure.

To give a contrarian example, though, the Jini designers tended to do just what you suggest. The Jini service item, for example, which returns three pieces of information from a Jini lookup service across the network to the client, is a "data transfer object" in J2EE parlance. And the service item uses public fields to hold those three pieces of data. That works fine when used as the designers intended. But I was working on a project where we wanted not to serialize the service item and send it across the network, but simply to hold onto a local cache and return it when requested. Because the fields were public, it wasn't immutable. So we couldn't really cache the service item, just its constituent parts. We had to create a new service item to hold the parts every time it was requested.

Immutable objects have several advantages. You can cache them. You can pass them to methods without making a copy. You can return them to methods without making a copy. That's the value (value, get it?) of data-oriented objects that have private methods with getters and setters.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Oh No! DTO!

Posted: Feb 27, 2004 2:06 AM

> Immutable objects have several advantages. You can cache
> them. You can pass them to methods without making a copy.
> You can return them to methods without making a copy.
> That's the value (value, get it?) of data-oriented objects
> that have private methods with getters and setters.

Oops. Of course I meant private variables and public getters and setters.

Another thing you can do with an immutable is use it as a hashtable key without fear it will change its value and render the object for which it is the key unfindable.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Oh No! DTO!

Posted: Feb 27, 2004 2:33 AM

> > Immutable objects have several advantages. You can
> cache
> > them. You can pass them to methods without making a
> copy.
> > You can return them to methods without making a copy.
> > That's the value (value, get it?) of data-oriented
> objects
> > that have private methods with getters and setters.
>
> Oops. Of course I meant private variables and public
> getters and setters.
>
No, what I actually meant was private variables and public getters. Public setters are rather uncool in immutables.

It's been a long day.

hackrobat

Posts: 14
Nickname: hackrobat
Registered: Jul, 2003

Re: Oh No! DTO!

Posted: Feb 27, 2004 4:18 AM

> > > Immutable objects have several advantages. You can
> > cache
> > > them. You can pass them to methods without making a
> > copy.
> > > You can return them to methods without making a copy.
> > > That's the value (value, get it?) of data-oriented
> > objects
> > > that have private methods with getters and setters.
> >
> > Oops. Of course I meant private variables and public
> > getters and setters.
> >
> No, what I actually meant was private variables and
> public getters. Public setters are rather uncool in
> immutables.
>
> It's been a long day.

You don't need private variables and public getters for immutable objects. Just make public final variables and initialise them in the constructor. That's what I do.

Of course, with public final references, the object being referenced itself needs to be immutable. So if you have a public final String reference, it's fine, but if you have a public final ArrayList, you can still add and remove from the ArrayList, which makes your immutable object Not Really Immutable (TM).

See my write-up here:
http://www.livejournal.com/~mannu/131085.html

hackrobat

Posts: 14
Nickname: hackrobat
Registered: Jul, 2003

Re: Oh No! DTO!

Posted: Feb 27, 2004 4:21 AM

I agree that data structures (data holders) should really be just that. I *hate* people who add getter and setter methods just for the heck of it.

C# has "properties", which are really like the getter-setter model, but you don't need to write code for the default behaviour, so your code is neat. Besides, it leaves no room for this argument ;-)

Rick Kitts

Posts: 48
Nickname: rkitts
Registered: Jan, 2003

Re: Oh No! DTO!

Posted: Feb 27, 2004 6:43 AM

I tend to think this argument is naive. Every place that you do class.member = 23 is surrounded by a context. An implicit definition of a set of acceptable values. While these may feel unconstrained and "obvious" today, all non-trivial systems end up getting bent in directions not originally envisioned or anticipated.

With a tight schedule and a change in the set of acceptable values for a member, developers are faced with a choice of rooting out all assignments to member and addressing the changing set (usually caused by a local only relevant context like "Oh, this time I'm using this DTO as part of an XYZ structure, member means this") by creating a setter or doing an in place if. What do you think they'll do? What have you <b>seen</b> them do. This will probably happen more than once in the lifetime of the code base. Probably lot's of times. Kruft accumulates. It happens. Seems to happen always.

If you argue that the the DTO should only have it's members set in one place then guess what, it's a setter. Put it on the DTO. Why not?

These rules are not created for people who write blogs and think passionately about the craft of development. They're created for the majority of developers. Well intentioned perhaps, reasonably intelligent, but in the end it's still just a job to them. Do it well sure, but the day ends and you go home and think about other things. Everything that is advised has to be advised with these people in mind. These are the consumers of design processes and guidelines. Not the people who actually care about them. Look, there's a reason for GUIs. Same rationale applies to this.

Finally any argument that has as it's premise or supports itself with developer convenience is, I belive, instantly suspect. You know what's inconvenient for me? Flood insurance. Gotta have it. It's the law. There hasn't been a flood here in like 100 years. But(!), there will be eventually. When there is the city recognizes it's simply better for me and my fellow citizens for me to have the insurance and not bog the city down with law suits, or wrecked houses I can't afford to build, or for them to have to show up at my door and throw me out because the house isn't safe.

Chris Dailey

Posts: 56
Nickname: mouse
Registered: Dec, 2002

Re: Oh No! DTO!

Posted: Feb 27, 2004 7:09 AM

And how does this fit in (Arthur J. Riel, "Object Oriented Design Heuristics"):

Beware of classes that have many accessor methods defined in their public interface, many of them imply that related data and behavior are not being kept in one place.

I think this is saying to be suspect of what is being called data structures in this discussion. Does it have weight? What does the code look like that accesses the data structure? Perhaps DTOs are an exception?

If DTOs are passed as arguments ("Curried object"), the receiving method should not do case analysis on the type, so DTOs should be final for the most part, right?

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Oh No! DTO!

Posted: Feb 27, 2004 8:24 AM

I disagree, and I just posted this to my weblog (http://beust.com/weblog):

Rob Martin wonders whether Data Transfer Objects (DTO, also known as value objects) should have accessors or not:

<<
The programmer was aghast. "DTOs are always made with private variables and getters and setters!" he said. "Why?" I asked.
>>

Rob argues that DTO's should not have accessors but only public fields, which should be the only way to access them:

<<
In my view OO programs contain two kinds of entities: Objects and Data Structures [...] On the other hand there is no good reason to use getters and setters in a data structure. A data structure is simply a packet of data, nothing more.
>>

While I agree with him about Objects and Data Structures, the point that Rob is missing is that it is quite common to start with a Data Structure and have it evolve toward an Object as your code changes over time. This has happened to me countless times and the few times where I gave in to the simplicity of declaring my Data Structures with public fields cost me some time when I had to change not only the said structure but all the calling code to use accessors and constructors instead of direct access.

Another reason why you should always use accessors for your DTO's is that of uniformity. When I am trying to get the value of an object, I don't want to have to thinkg "mmmh... is Employee a DTO or an Object? I think it's a DTO so I'll just write employee.firstName... oops, no, I forgot it's an Object now, so I have to use employee.getFirstName()".

Uniformity is crucial. I already have enough to think about when I write my code, I don't want to spend my time second guessing myself or having to browse the class I want to use before I can do something as simple as getting a value.

--
Cedric

todd hoff

Posts: 22
Nickname: thoff
Registered: Jan, 2004

Re: Oh No! DTO!

Posted: Feb 27, 2004 9:08 AM

Properties in java would be cool. I remember hearing
about them for the first time and thinking what an
excellent idea.

I agree if it is strictly a DTO accessors
aren't necessary.

Maybe the accessor mind-set comes from the bean idea
where getters and setters define the interface. But
if this isn't a bean it won't matter.

The issue of DTO migration into class-hood is an
issue though. Does it happen a lot that you
want to copy object data into a DTO to save it to
the database? Don't you usually want to go directly
from the object and not use an intermediary format?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Oh No! DTO!

Posted: Feb 27, 2004 11:08 AM

> You don't need private variables and public getters for
> immutable objects. Just make public final variables and
> initialise them in the constructor. That's what I do.
>
I don't usually do that, mainly because mutables with get methods are idiomatic in Java. I don't find them offensive or hard to use at all, and in my IDE creating those get methods is one mouse click.

I do agree that an object that just has data and has both get and set methods is a design that deserves scrutiny. Maybe there's a good reason for it, but if refactoring is needed my design nose usually leads me to make the thing immutable, with just get methods, rather than just having public data.

Nevertheless, there is no absolute right way to do things in all cases. One example of a design that uses public fields that I think is perfectly justifiable is JavaSpace entry objects. Ken Arnold described the process they went through to decide to make those fields public instead of private with get and set methods here:

http://www.artima.com/intv/sway2.html

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Oh No! DTO!

Posted: Feb 27, 2004 7:10 PM

> Immutable objects have several advantages. You can cache
> them. You can pass them to methods without making a copy.
> You can return them to methods without making a copy.
> That's the value (value, get it?) of data-oriented objects
> that have private methods with getters and setters.

Do you think you could achieve the same ends with public final variables that are set in a constructor?

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Oh No! DTO!

Posted: Feb 27, 2004 7:18 PM

> These rules are not created for people who write blogs and
> think passionately about the craft of development. They're
> created for the majority of developers. Well intentioned
> perhaps, reasonably intelligent, but in the end it's still
> just a job to them.

I reject this argument rather vehemently. We do no service to our profession by dumbing it down. It is better to educate than legislate.

Rather than teach practices that are "safe" for the mediocre developer; we need to teach the mediocre developer how to be better. We don't do that by recommending practices that we justify only with: "We want you to do this because we're afraid you're a slug."

Flat View: This topic has 31 replies on 3 pages [ 1 2 3 | » ]

Previous Topic

Next Topic