OOP Encapsulation Philosophy

Question

Is it fair to say that it is good practice to default everything to private up when defining a class?

For example, for my public interface I would set my class something like this:

class foo {
    private var x
    private var y

    //even get and set are private, 
    //public only if necessary
    private get/set method for variables

    //main function
    private coreFunc () {...}

    //helper function 
    public  callCoreFunc() {
    coreFunc()
 }
}

I'm used (and got used from my algorithm teacher) that everything in a class should be private, except for the methods that the user need to call (with wrapped helper function.)

Is this a good way to see "public interface" or is this too strict?

maybe you could expand your question a bit. currently, yes if it doesn't need to be public then the default is private — Ewan, Sep 14 '18 at 08:51
adding extra public helper functions that just call the private function is a bit weird though — Ewan, Sep 14 '18 at 08:52
Uhm, I'm doing the "public func call private" to "protect" my core function (which is coreFunc), because the final user should only see the method but not the implementation of the code (or at least i suppose). Do you think it's a little bit overkill? @Ewan — Asynch_, Sep 14 '18 at 08:56
@Asynch_: Can you explain how the wrapper function prevents the final user from seeing the implementation of the core function? — Bart van Ingen Schenau, Sep 14 '18 at 09:06
I think you have a misunderstanding of what the access modifiers do. — Ewan, Sep 14 '18 at 09:12
In a philosophic way. The user should only call function that he needs to, in this case coreFunc. To not let the user access to the main function (coreFunc) i create another helper function to wrap my private function in. In this case, yes, the user can still use my coreFunc but "encapsulated" into another public one visible to the user. That's why I'm talking about "Philosophy", because the implementation just work with all the kind of public/private combination possible. My question was: Which of them is the best one from a practical view? — Asynch_, Sep 14 '18 at 09:13
@Asynch_, in a practical view, your wrapper function does not achieve anything but causing confusion. You can just as easily set the access modifier of `coreFunc` to `public` and let the compiler (by throwing an error for attempts to access a private member) and documentation (by not mentioning the private members as part of the API) do the rest. — Bart van Ingen Schenau, Sep 14 '18 at 09:28
@Asynch_ Why would you not let the user access the function he needs to call? — Stop harming Monica, Sep 14 '18 at 09:32
Possible duplicate of [Why do we need private variables?](https://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables) — curiousdannii, Sep 14 '18 at 10:05
@Asynch I'll add one tip, which I wasn't taught in school, but on the job. When you have a public property setter, you should validate the new value and throw exceptions when it isn't valid. To help me remember this, my mentor told me: "If you don't validate inputs, you don't have encapsulation." — Nick Alexeev, Sep 18 '18 at 01:33

score 3 · Accepted Answer · answered Sep 14 '18 at 13:15

It's certainly true that it's best to make everything private unless it needs to be public is a good starting point.

But making important member functions private, and then writing public wrapper functions so that they may be called, doesn't really achieve anything.

From a code efficiency perspective, you've added an extra function call each time the member function is called, and you've bloated your code base with extra functions.

From a code hiding point of view, you haven't actually hidden anything. In languages (such as Java) which don't have separate "headers" and "bodies" it makes no difference - if the user can see the wrapper then they can see the code. In languages that do have separate headers, such as C++, then the wrapper will be in the same body as the function it wraps. So the user will see both if they have access to the body, or neither if they don't.

Unless you're selling proprietary software, private in OO isn't really about hiding code from people. It's about clearly separating the bits that are the public API of a function from the implememtation details, and making sure the caller can only access the bits they are intended to.

OOP Encapsulation Philosophy

1 Answers1