2

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?

|improve this question
  • 1
    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 8:51
  • 2
    adding extra public helper functions that just call the private function is a bit weird though – Ewan Sep 14 '18 at 8:52
  • 2
    @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 9:06
  • 2
    @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 9:28
  • 1
    @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 1:33
3

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.

|improve this answer

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.