Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^3: OOP: How to (not) lose Encapsulation

by hobbs (Monk)
on May 12, 2015 at 21:52 UTC ( #1126469=note: print w/replies, xml ) Need Help??

in reply to Re^2: OOP: How to (not) lose Encapsulation
in thread OOP: How to (not) lose Encapsulation

There's no dogma here, just a set of well-worked examples of what could go wrong with code reuse in certain scenarios, how encapsulation can help, and honestly, how it can also make things more complicated. Is there any particular reason you chose to resort to mindless name-calling?
  • Comment on Re^3: OOP: How to (not) lose Encapsulation

Replies are listed 'Best First'.
Re^4: OOP: How to (not) lose Encapsulation
by Your Mother (Archbishop) on May 12, 2015 at 22:11 UTC

    There was no name calling; restrictive and prohibitive are simple adjectives and they seem applied correctly. There is implied dogma in the OP. Having an opinion about OOP either way is not mindless.

Re^4: OOP: How to (not) lose Encapsulation
by Anonymous Monk on May 12, 2015 at 22:13 UTC
    "restrictive and prohibitive" are not examples mindless name-calling. Those are called opinions. So, as you can see, your question is loaded. Oh, did you mean "OOPolice?" If you took offense to that then maybe you rightly were called out for being one.

    Now, if you had asked a better question, like "Why do you find this to be restrictive and prohibitive" then maybe we could have a more meaningful conversation. The answer is: because I find them to be unnecessary and a waste of my time. If Betty wants to reach into an object and access its internals, go right ahead. Freedom. As with pretty much any engine out there, you void the warranty when you break encapsulation but why should that stop you if you know what you are doing. These methodologies are for people who don't know what they are doing. And those people shouldn't be doing, they should be learning.

      Pretty much any engine out there is by design hidden within some (usually restricted) compartment.

      But this meditation isn't about making the engine inaccessible, it's mainly about designing in such a way that it's more obvious to Betty where the boundary between internal and external is, so it's harder to unintentionally abuse the internals.

Re^4: OOP: How to (not) lose Encapsulation
by sundialsvc4 (Abbot) on May 13, 2015 at 13:50 UTC

    I just enjoy what works, in a particular application.   (And all applications are different.)   It so happens that I like to use things which help me put “all of the relevant code” into one place, and to “hide” things so that the compiler will detect situations where another piece of code (which I never would have found, among hundreds of source-code modules that I didn’t write) might interfere with another, or have a dependency on it, or introduce unwanted side-effects upon it.

    Now, the Perl language is weak in that regard ... because of the legacy design of the language and because Moo/Moose are really “just puddings” that have been subsequently grafted onto it.   But that can’t be helped and I’ll take what I can get.   Gladly.

    I suppose that I “lack dogma” because, most of the time, I am dealing with troubled, legacy systems which I did not write and for which the original programmers are long-gone.   I’m trying to make improvements to a system that is chock-full of design problems which caused the original team to split the coop.   OOP techniques work well for me, then.   I am often trying to consolidate maybe-hundreds of redundant, sometimes not-quite identical, pieces of code that are scattered all over Casablanca, and to put them into just one place.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (1)
As of 2022-08-07 19:22 GMT
Find Nodes?
    Voting Booth?

    No recent polls found