Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^3: OOP's setter/getter method - is there a way to avoid them?

by Laurent_R (Canon)
on Oct 27, 2015 at 14:54 UTC ( [id://1146123]=note: print w/replies, xml ) Need Help??


in reply to Re^2: OOP's setter/getter method - is there a way to avoid them?
in thread OOP's setter/getter method - is there a way to avoid them?

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.

  • Comment on Re^3: OOP's setter/getter method - is there a way to avoid them?

Replies are listed 'Best First'.
Re^4: OOP's setter/getter method - is there a way to avoid them?
by tiny_monk (Sexton) on Oct 28, 2015 at 03:39 UTC

    Thank you, Laurent_R. After reading the string of comments on this node , the ideas you shared started making more sense. I am starting to appreciate the significance of getter/setter functions though I have to admit that I am still conscious about not breaking an object's encapsulation - even to the extent of not breaking it inside an object. However, I am learning that it is perfectly alright since setter and getter functions reside inside an object, or, even better, a class. Thank you again for sharing your ideas. :)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1146123]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (3)
As of 2024-04-26 05:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found