> 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.
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
[
«
|
123
]
Previous Topic
