Geeks With Blogs
Boy Meets 'Hello World' Blogging the journey from College Grad to .NET Developer

This is a weakness of mine that I just can't seem to shake, and I think it's starting to affect my productivity. As the single OOP developer at work, I don't have a senior developer to smack me over the head and say "get over it." Basically, I've been taught to keep my data encapsulated. At some point, the user wants it back. I don't want to give it to them.

Somewhere in the past few days, I saw on a blog someone mention the "getters are evil" camp, referring to Allen Hulob's article, <a href="Somewhere in the past few days, I heard someone group together people in the " getters are evil" camp, referring to Allen Hulob's article, . I guess I would be one of those people, not necessarily that any getter is evil, but I guess I strive harder than others to create objects which don't just show their data. Perhaps it's my ">"Why getter and setter methods are evil". I guess I would be one of those people, not necessarily that ANY getter is evil, but I think I strive harder than others to create objects which don't just show their data. I don't obviously go as far as Allen describes in his harshly critiqued article....

One ramification of full field encapsulation is in user interface (UI) construction. If you can't use accessors, you can't have a UI builder class call a getAttribute() method. Instead, classes have elements like drawYourself(...) methods.

I'll admit, I've actually thought about doing this... having the domain object have a method that allows the object to draw itself, and making, say, an HTML implementation of whatever object I pass to that method. I'm sure I played a video game instead, and I bet I got more out of it, but every once and awhile it still comes back to me.

I've found joy in developing code that is actually easier to understand and more succinct by having my object model use more void methods and less getters / query methods. But when I start thinking about the whole idea of encapsulation, the goal is to abstract away the data from anyone who uses that object. Typically, that person using the object is myself or another programmer. Generally, if you wanted to trust your data to someone, all things being equal, you would trust it to a programmer versus someone from marketing. And certainly you find greater trust in yourself than others. And yet this data that I have in my object, this data that I hide from fellow programmers so that they won't become coupled to it, this data that I hide from myself so that I can easily maintain it; I must show to my users?

Needless to say, I HATE doing user interfaces, and I don't mean the making things flashy part. I'll go through hoops to make my objects return DTO's from a BuildDTO() method, rather than expose them from getters. It's not that I think that methods are "better" than getters, it's just that now I have one member leaking my abstraction rather than all of them.

Honestly, I REALIZE that this is silliness. But still, I've often thought about how I would want it done. The user clicks on the "Modify Customer" button. Rather than getting a page representing a customer's record, they get a page that represents a form to change the customer's record. I would have an object that generates a form based on a customer record, and another object that handles the retrieved forms. These forms themselves are objects. But in the end, all these objects will need to get their data from somewhere, which means there would be somewhere an object exposing state.

And that bugs the hell out of me.

Posted on Thursday, June 5, 2008 7:36 AM | Back to top

Comments on this post: I give up. I just can't hide my object states forever...

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © mhildreth | Powered by: