Why are private variables described in the publicly accessible header file

language-featuresprogramming-languages

OK, so hopefully this is a subjective enough question for Programmers, but here goes. I am continuously broadening my knowledge of languages and software engineering practices… and I've run into something that just makes no sense to me whatsoever.

In C++, class declarations include private: methods and parameters in the header file, which, theoretically, is what you pass to the user to include if you make them a lib.

In Objective-C, @interfaces do pretty much the same thing, forcing you to list your private members (at least, there's a way to get private methods in the implementation file).

From what I can tell, Java and C# allow you to provide an interface/protocol which can declare all the publicly accessible properties/methods and gives the coder the ability to hide all implementation details in the implementation file.

Why? Encapsulation is one of the main principles of OOP, why do C++ and Obj-C lack this basic ability? Is there some kind of best-practices work-around for Obj-C or C++ that hides all implementation?

Thanks,

Best Answer

The question is whether the compiler needs to know how large an object is. If so, then the compiler has to know about the private members in order to count them up.

In Java, there's primitive types and objects, and all the objects are allocated separately, and the variables containing them are really pointers. Therefore, since a pointer is a fixed-size object, the compiler knows how big a thing a variable represents, without knowing the actual size of the pointed-to object. The constructor handles all of that.

In C++, it's possible to have objects represented locally or on the heap. Therefore, the compiler needs to know how big an object is, so that it can allocate a local variable or array.

Sometimes it's desirable to divide class functionality into a public interface and a private everything else, and that's where the PIMPL (Pointer to IMPLementation) technique comes in. The class will have a pointer to a private implementation class, and the public class methods can call that.

Related Solutions

Java Access Modifiers – Why Are Protected Members Accessible to Same Package Classes?

looking for a specific use case where both a subclass and a class within the same package needs to access a protected field or method...

Well to me, such a use case is rather general than specific, and it stems from my preferences to:

Start with as strict access modifier as possible, resorting to weaker one(s) only later as deemed necessary.
Have unit tests reside in the same package as tested code.

From above, I can start designing for my objects with default access modifiers (I would start with private but that would complicate unit testing):

public class Example {
    public static void main(String [] args) {
        new UnitTest().testDoSomething(new Unit1(), new Unit2());
    }

    static class Unit1 {
        void doSomething() {} // default access
    }
    static class Unit2 {
        void doSomething() {} // default access
    }

    static class UnitTest {
        void testDoSomething(Unit1 unit1, Unit2 unit2) {
            unit1.doSomething();
            unit2.doSomething();
        }
    }
}

_{Side note in above snippet, Unit1, Unit2 and UnitTest are nested within Example for simplicity of presentation, but in a real project, I would likely have these classes in separate files (and UnitTest even in a separate directory).}

Then, when a necessity arises, I would weaken access control from default to protected:

public class ExampleEvolved {
    public static void main(String [] args) {
        new UnitTest().testDoSomething(new Unit1(), new Unit2());
    }

    static class Unit1 {
        protected void doSomething() {} // made protected
    }
    static class Unit2 {
        protected void doSomething() {} // made protected
    }

    static class UnitTest {
        // ---> no changes needed although UnitTest doesn't subclass
        // ...and, hey, if I'd have to subclass... which one of Unit1, Unit2?
        void testDoSomething(Unit1 unit1, Unit2 unit2) {
            unit1.doSomething();
            unit2.doSomething();
        }
    }
}

You see, I can keep unit test code in ExampleEvolved unchanged due to protected methods being accessible from the same package, even though accessing object is not a sub-class.

Less changes needed => safer modification; after all I changed only access modifiers and I did not modify what methods Unit1.doSomething() and Unit2.doSomething() do, so it is only natural to expect unit test code to continue run without modifications.

Java – Why Is There No ‘Subclasses-Only’ Access Modifier in Java?

Java originally had such a modifier. It was written private protected but removed in Java 1.0.

I assume that was a judgment call that the extra complexity wasn't worth the cost.

Every language feature has a cost: in teaching it to new programmers; in documentation; in implementing it in the compiler, JVM, and dev tools; in reasoning about program correctness; in constraining future language evolution; and more. Language features interact with each other, potentially with N² interactions.

What percent of Java programmers have read through the Java language spec and VM spec? I bet it's a small percentage, which argues for an even simpler language for the sake of understandability and engineering products that we can depend on

The benefit of the private protected feature was small since the package is the main unit of modularity.

Best Answer

Related Solutions

Java Access Modifiers – Why Are Protected Members Accessible to Same Package Classes?

Java – Why Is There No ‘Subclasses-Only’ Access Modifier in Java?

Related Topic