laziness, impatience, and hubris | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Well, to sort of mitigate what I said previously, if I were to design a class in which all object attributes were to have simple getters and setters, and in which there was no other way to use or modify these attributes than these getters and setters (and the initial constructor), then, my class might still work fine for its intended purpose, but it would likely be poor OOP design. Or it would at best be a use of an OO interface / functionalities to do something else than real OO programming, perhaps, for instance, to simply benefit from data encapsulation and relative persistence from one call to another. And this might be perfectly OK if I don't fool myself into believing that I have created a real OOP design.
So, yes, accessors might sometimes be harmful if I use them lavishly in order to, in fact, avoid creating a real OO design, but the problem here is not so much my excessive use of accessors, but rather perhaps my own lack of experience in OO programming or my lazy reluctance to actually design a real OO application. I have seen at work many Java programs that are not OOP at all: they were just purely procedural programs written in Java (or maybe I should say written in C with a Java syntax) rather than in actual C, presumably just because it is easier not to have to deal with the pitfalls of memory allocation, memory leaks, dangling pointers, segmentation faults and other traps of the C language. Well, why not if it make things easier? But, if you do that, just be aware that it is not true OO programming. My own son (who is preparing a PhD in IT) is frequently using C++ just as if it were pure C, just using some of the facilities offered by the C++ (non-OO) syntax. Again, why not? But this is no OO design. Conversely, I am using relatively regularly closures and related FP features to implement data encapsulation and persistence, and creating my own getters and setters, a kind of very light-weight object methodology in a way, but this is also not OO programming. So, in brief, I don't think there is anything wrong or even dangerous about accessors in OO programming per se, except that, if I am not careful about what I do, I might simply not be doing true OO programming, but just (cleverly or lazily, it is your draw) using some of the useful tools provided by the OO framework and functionalities in Perl or whichever language in which I happen to be developing. In reply to Re^3: OOP's setter/getter method - is there a way to avoid them?
by Laurent_R
|
|