• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is including Mutable Objects in VO/DTO pattern a violation of OO Programming ?  RSS feed

 
Arvind Sampath
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey All,

I've been having this very doubt for quite a long time. In the Value Object pattern, the instance variables are supposed to be private and the corresponding getters/setters would be public. If we include a mutable object(say another value object) as a private instance variable and provide a public getter method, anybody who has access to getter method can change the mutable object. Isnt this a violation of OO programming ?

I've been using value objects with mutable objects for long. Am still unsure whether it is right or not according to OO programming.

Would be glad if someone can throw light on this.

Cheers
Arvind
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Value objects with getters & setters for every field and no other behavior are already pretty weak objects. They are pretty much C structs with a lot of boiler plate accessor code. So, further watering down the object oriented goodness by letting somebody modify an object held as a field is hardly something to get excited about.

If I had a really robust object, one that hid all of its data and only exposed its behavior, I'd avoid exposing an object held as a field. Keeping your objects private is part of the Law of Demeter.
 
Arvind Sampath
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stan,

Thanks for the info. I had done a handfull of Object Oriented Design courses, but I was never aware of the existence of this Demeter law. Going by the searches that google returned for 'Law Of Demeter', I do understand how week our objects are in the presence of accessors. Dont you think this law is a kind of a revolution against JavaBeans ? I am very much interested in this law. I went through this article from Java World. Considering the fact that almost all MVC apps use Java Beans, I dont find any reason for this law not being adopted(atleast nobody follows it or is aware of it at my workplace). Ofcourse there is this extra overhead of the object doing the extra work for its callers...



Cheers
Arvind
 
Arnold Reuser
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why not use the following recipe : define for each bean a corresponding interface which will only state the getters of the bean.
As a result each SomeBean implements ISomeBean.
This construction will allow you to use the interface throughout your code without having the possibility to change the underlying bean.
 
Arvind Sampath
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As a result each SomeBean implements ISomeBean.
This construction will allow you to use the interface throughout your code without having the possibility to change the underlying bean.


I dont think this is going to be of any real use. Can you tell me a way in which the interface is improving the situation ? We are talking about a Java Bean which has only getters/setters. Even in the conventional VO/DAO pattern, the code inside the getters/setters can change without affecting the clients which are accessing it. The problem occurs when we have to change our return types which means that we have to modify the code at all the places where we are accessing the method. Even if we use an interface, the problem remains unsolved.

Morever, I dont see the interface as a solution to any of the problems that Stan mentioned.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JavaBeans with all the getters & setters were created for a specific purpose, to allow tools like IDEs to dynamically discover the attributes and manipulate them with reflection. That is NOT a good pattern to follow in the main body of your own code. Strive for the "tell, don't ask" style of designs, let your objects define themselves by behavior rather than data.

Ideal perfection is not always practical, and the boundary between your best object model and some non-object interface like a database or remote communication protocol will often involve some compromised designs. Still, any time you write a get or set method is a good time to stop and think a little longer.
 
Arvind Sampath
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JavaBeans with all the getters & setters were created for a specific purpose, to allow tools like IDEs to dynamically discover the attributes and manipulate them with reflection.


I dont where/why IDEs use them. But one place where getters/setters are of utmost use is like a place where struts populates the ActionForm objects with the input form data and where out Action class retrieves the form data.

Still, any time you write a get or set method is a good time to stop and think a little longer.


I have this very situation where everybody in our office uses getters/setters. Honestly, I thought for some time. But i couldnt come with an alternative for this. So let me put it right in front of all. I have to pass 15 odd parameters to my Oracle Stored Procedure from my Servlet. I wrap the request parameters in a conventional Java Bean and pass it to the DAO class. My DAO class unwraps them and sends it the DB. Similarly I want to pass User information, say another 15 odd user parameters, to my jsp from Servlet. I, again, wrap the info i got from the DAO in a Java Bean and put it as part of the request attribute and forward the request. Now, dont you think these are ideal situations for Java Beans. Of course our Java Bean becomes a weak object. But, is there a better alternative?
[ May 02, 2006: Message edited by: Arvind Sampath ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure there is a viable alternative. A DTO doesn't even seem like an object to me, where's the behavior? It's just a container for data. But we live in an imperfect world and we have to interact with imperfect hardware and software, so sometimes the best solution isn't pretty.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Transferring data from one layer to another remote one is one of those boundaries I mentioned. I haven't found a way to keep robust objects that I'd be proud to show my Mother across those boundaries. Often any behavior an object might have on one side is just not appropriate on the other.

I write DTOs off as a necessary evil. They're not "good" objects; they're COBOL copy books or C structs. Then I wonder why have private fields and getters and setters anyhow? If it's just a struct, make fields public, forbid any behavior and use them only where absolutely necessary on these boundaries.
 
Arvind Sampath
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I write DTOs off as a necessary evil. They're not "good" objects; they're COBOL copy books or C structs.


They might not be "good" objects. But they serve the purpose, dont they? And I dont think it is possible to write them off, if you are designing an MVC app in particular

Then I wonder why have private fields and getters and setters anyhow? If it's just a struct, make fields public, forbid any behavior and use them only where absolutely necessary on these boundaries.


It is still better to have getter/setters and private fields rather than making the fields public. That way we shall have some control over our object's state
[ May 04, 2006: Message edited by: Arvind Sampath ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, they serve a purpose. I left "necessary" in my rant. You gotta have them some times. Maybe.

MVC is not what makes them necessary. We had decades of very nice MVC designs with no DTOs. Communication over some non-object protocol makes them necessary. The T is Transfer after all.

If we use them only as a message body going over a protocol the responsibility for maintaining valid state goes on the message sender or receiver or both, not on the message itself. We might as well use XML, CSV or delimited strings.

That's an admittedly narrow focus view on DTO with strong emphasis on the T. YMMV.
 
Arvind Sampath
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If we use them only as a message body going over a protocol the responsibility for maintaining valid state goes on the message sender or receiver or both, not on the message itself. We might as well use XML, CSV or delimited strings.


I would say there could never have been a better precise gist than this.Hats off to you ! I guess you were/are a Prof. (atleast a freelance Prof.)

We had decades of very nice MVC designs with no DTOs. Communication over some non-object protocol makes them necessary


Non-object protocol !!! Would you mind elaborating a little ?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I started looking through Sun's J2EE pattern catalog at the places they use Transfer Object (formerly Value Object) in their diagrams. They're often annotated as "serialized" going between the servlet container and the EJB container. I guess those are some of the interfaces I was thinking as non-object. XML/HTTP is even worse, because the client and server don't even pretend to have object parameters and return values.

File systems or SQL are non-object interfaces, too, but we don't pass DTOs between Java and the database, we pass DTOs between DAOs and businessy objects. I'm not sure there's any reason to do that. Why should the DAO create a dumb structure instead of a full blown behavior based object with private data? Just because it's harder to do with a generic DAO framework?

I'm mostly making this up as I go. Is it making sense?
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!