Please Stop Misguiding Our Youth

 Abhi: I’m going to disagree with your last paragraph, but only on a very nit-picky kind of way 🙂

I believe that it is easy to confuse hiding data with providing a clean interface. The idea of a functional contract between components does not *require* any kind of restriction, it simply requires that the interface through which the function is provided does not change.

This contract may be provided in the form of documentation, naming conventions, even a simple phone call to describe that single method used as an entry point to a library. It can even go so far to say that a contract is made by simply keeping the client code ignorant of internal attribute names, so that they won’t use them. If you hack the library to find and use the internal symbols, you should not be surprised when the library starts acting weird, right?

The public and private keywords are specific to languages like C++ and java, and the only reason that I could see a use for them is if the person writing client code was actually reading the headers that defined the class. Including type headers (which is only a convention!) is a language-specific thing, and do not *facilitate* this contract, they only provide a semantic (compile-time!
) helping hand for a language’s *implementation* to remind a programmer that they are breaking the contract.

If I were teaching an OO basics class, I would not teach that “encapsulation” is necessary for object-orientedness. Instead I would focus on the idae of clean *abstraction*, which is the separation of components to ensure that one can be changed without affecting the other. This can be just easily be achieved by providing a wrapper class, or naming methods using an underscore convention like “_handsOffThisWillBreakTheContract”, or simply keeping the names of the “private” methods and attributes out of the docs, whether those docs are defined as the html user docs or the class header file itself.

I will say that I am tired of hearing that encapsulation has anything to do with object oriented programming. Shoot, even abstraction is only necessary  in *some* cases, and it can just as easily be achieved in a structured language like C, and so also has nothing to do with object oriented programming.

The “object oriented” concept provides nothing more than a thin semantic helping hand, in the form of a real-world representation instances of stageful types that provide a function. Everything else is nothing more than language implementation.

By | 2010-12-17T01:47:00+00:00 December 17th, 2010|Uncategorized|5 Comments

5 Comments

  1. Rafe Kettler December 17, 2010 at 4:13 pm - Reply

    Amen. I stopped writing getters and setters when I started using Python and I never looked back. Really, it should ONLY be done in an API or when there’s something special beyond simple access that needs to be done when an attribute’s get or set.

  2. Eric Larson December 17, 2010 at 5:14 pm - Reply

    I think the whole getters/setters == encapsulation should go away. Encapsulation is really important, but not because it hides something. What does it matter if you change the way something is retrieved behind the scenes? What matters is that you have a place to abstract complexity and that is the most important aspect. Battling complexity is probably the single most important thing a programmer can learn because it is at the core of computing. Encapsulation is a great way to hide complexity, not implementations.

  3. wapcaplet December 20, 2010 at 6:40 am - Reply

    I totally agree. The C++ getter/setter habits that I was taught in university stuck with me for years, until I started Python and realized they were a waste of time. I too have never looked back. Now it makes me cringe when I see this behavior in people’s Java code, until I remember they’re Java programmers, and don’t know any better.

  4. Abhi January 7, 2011 at 5:00 am - Reply

    If your class is just using getters and setters for internal member variables, then it’s not much of a class. “Encapsulation” means providing a higher level of abstraction to callers than simply exposing internal members to them.

    So if your class only consists of setters and getters, by all means throw them away and just make everything public — it’s nothing but a simple function-less struct anyway.

    But to extend from that to say that the concepts of encapsulation, client code, public and private variables, etc are unnecessary is stretching it too far. Those concepts are absolutely essential to writing any medium to large sized app — but only in the hands of someone who knows how to use them appropriately.

  5. Patricio January 8, 2011 at 9:00 pm - Reply

    Abhi: Yeeaahhhh, I’m going to have to go ahead, and sort of…disagree with you there. But only on a very nit-picky kind of way 🙂

    I believe that it is easy to confuse hiding fragile data with providing a good, cleanly abstracted interface. The idea of a functional contract between components does not *require* any kind of restriction (i.e. encapsulation), it simply requires that the interface through which the function is provided does not change.

    This contract may be provided in the form of documentation, naming conventions, even a simple phone call to describe that single method used as an entry point to a library. It can even go so far to say that a contract is made by simply keeping the client code ignorant of internal attribute names, so that they won’t use them. So if you go and hack a library to find and use the internal symbols, you should not be surprised when the library starts acting weird, right?

    The public and private keywords are specific to languages like C++ and java, and the only reason that I could see a use for them is if the person writing client code was actually reading the headers that defined the class. Including type headers (which is only a convention!) is a language-specific thing, and do not *facilitate* this contract, they only provide a semantic helping hand at compile time for a language’s *implementation* to remind a programmer that they are breaking the contract.

    If I were teaching OO 101, I would not teach that “encapsulation” is necessary for object-orientedness. Instead I would just focus on the idea of clean *abstraction*, which is the separation of components to ensure that one can be changed without affecting the other. Further, abstraction can be an important concept even when you are working on a code base that will never be used by another person! That’s because sometimes having meaningful names and separation makes it easier to design your code, but also sometimes you will write so much code that you don’t remember what some parts do and you are forced to rely on a clean, self-documenting abstraction to help you remember. Abstraction can be easily achieved by providing a wrapper class, or naming methods using an underscore convention like “_handsOffThisWillBreakTheContract”, or simply keeping the names of the “private” methods and attributes out of the docs, whether those docs are defined as the html user docs or the class header file itself.

    I am tired of hearing that encapsulation has anything to do with object oriented programming. Shoot, even abstraction is only necessary in *some* cases, and it can just as easily be achieved in a structured language like C, and so also has nothing to do with object oriented programming.

    The “object oriented” concept provides nothing more than a thin semantic helping hand, in the form of a real-world representation by creating instances of stateful types that provide a function. Everything else is nothing more than language implementation.

Leave A Comment

− 1 = 1