tag:blogger.com,1999:blog-6098392112071095875.post7226251200934459312..comments2012-02-04T21:36:06.292-05:00Domingos Netonoreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6098392112071095875.post-33568092534807277992009-12-26T18:49:54.318-05:002009-12-26T18:49:54.318-05:00I want to quote your post in my blog. It can?<br />And you et an account on Twitter?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6098392112071095875.post-35394796533421890492008-10-04T22:24:00.000-04:002008-10-04T22:24:00.000-04:00Well, but how to handle interfaces to the things out of the system? For example, how to put/get data into/from databases? Or to/from GUI widgets?<BR/>You can cite Naked Objects, but that assumes OO is "the" way we all should interact with automated information systems, which I strongly disagree.Mhttp://www.blogger.com/profile/12041279614721173438noreply@blogger.comtag:blogger.com,1999:blog-6098392112071095875.post-13834995009487432762008-08-03T16:36:00.000-04:002008-08-03T16:36:00.000-04:00Hi Tim,<BR/><BR/>If getters and setters are evil, making your attributes public is even worse :) This is not what I was trying to suggest here.<BR/><BR/>I understand your point about how to build a DTO and I agree that it should not be the Domain Object's responsibility to do it.<BR/><BR/>This is the kind of 'real life' problems I was talking about, and this is why I cannot be purist and advocate the end of getter and setter methods.<BR/><BR/>What is important is to make sure you expose only what is strictly necessary. If you have to add a setter or a getter fine, just ask yourself if you really need it before doing it.Domingos Netohttp://www.blogger.com/profile/16748499695622931125noreply@blogger.comtag:blogger.com,1999:blog-6098392112071095875.post-91461273065273281012008-08-03T00:50:00.000-04:002008-08-03T00:50:00.000-04:00Hmm... I'm not so sure "evil" is the word I'd use. Inelegant, yes. But rare is the client-server beast that I have seen where your fully OO business classes can be blindly serialized across the ether without concerns for bandwidth and/or memory usage. The solution for this typically is a DTO. But then whose job is it to create the DTO? If your answer is the object itself, then you are digging yourself into the hole of presentation-specific concerns (what happens when the next screen wants to see different data?). Also, how do you create one of these objects from data entered by a user screen? A giant constructor?<BR/><BR/>I guess the point is that getters/setters provide false encapsulation. Ok, so go ahead and make the attributes public. The problem with that is when you finally decide you want to slip in that "if" statement before the value is gotten (or setten), for example for lazy loading and caching. To do that, you'd have to go back and manually change all direct references to the attribute.<BR/><BR/>So, if they're evil, I'd say they're a lesser evil, or just plain inelegant. C# got it right, IMHO. ALL references to attributes are implicit calls to getters or setters. You don't have to write the stupid method if all it does is return or set the value. But if the day comes when you DO want to slip in a Mickey, you can explicitly declare the mutator without any change to your class' clients.Timhttp://www.blogger.com/profile/02875419702912127791noreply@blogger.com