The Artima Developer Community
Sponsored Link

Weblogs Forum
Oh No! DTO!

31 replies on 3 pages. Most recent reply: Apr 26, 2007 2:45 AM by Risto Peränen

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 31 replies on 3 pages [ « | 1 2 3 ]
Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Oh No! DTO! Posted: May 16, 2006 7:49 AM
Reply to this message Reply
Advertisement
> 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?

Basically OO is totally wrong, because it blends tuples, classifications, interfaces and events in one big mess...and that is why you are asking "why indeed"...

The correct approach would be to separate those. The programmer should be able to declare separately:

1) tuples or records or structures.
2) classes; FPLs lik Haskell got it right (ML to a degree).
3) interfaces as functions with the same name but different number/types of parameters.
4) events; such as changing a value of an object (size of a widget, for example), adding an element to a list etc.

Risto Peränen

Posts: 1
Nickname: rperanen
Registered: Apr, 2007

Re: Oh No! DTO! Posted: Apr 26, 2007 2:45 AM
Reply to this message Reply
Uncle Bob is absolutely right that getters and setters are plain stupid. They should be avoided at all costs since they are just another way to write data-members public. They don't hide the implementation at all which was the main goal of Object-Oriented programming.

I do like about threading and kinky-stuff like that. The data-records don't mix very well in that kind of tasks. Should I use getter/setter there to lock/unlock mutexes?

In my experience it is always better to define import/export-interfaces than define getter/setter for each field. Good points are (in threaded environment)

* It is much easier to control data-accesses when there is always single interface that can lock critical section before exporting or importing, import/export everything you need at once and then release lock for critical section. Another good reason is that with import/export interface you can have "snapshot" of the data you want to handle. With getter/setter there is always a change that data has been changed between get/set-calls. Sure you can define lock-unlock methods to data-object itself but that is also nasty and takes focus of actual problem to locking instead.

* Testing is easier since it is enough to test only data-object with dummy export/import and export/import implementation with dummy-data-object.

With getter/setter you have all bad sides about OO but none of the good ones. With exporter/importer you have bad sides (too much typing) but also good sides (abstraction) of OO.

PS: Sorry about my rotten language. I am not a native speaker :)

Flat View: This topic has 31 replies on 3 pages [ « | 1  2  3 ]
Topic: Oh No!  DTO! Previous Topic   Next Topic Topic: Comparing Inner Class/Closure Proposals


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us