This is particularly useful when authoring libraries as I know that for anything not public, I can refactor to my hearts content (provided the externally observed behaviour is otherwise unchanged).

It’s a bit of a pity that it was only relatively recently that Visual Studio changed the template for new classes to use internal instead of public.

There are lots of public classes in codebases I work on which are probably only public due to the old default and not used externally so could be refactored, but it’s hard to be sure.

Whereas with internal classes I can be sure (unless someone has used reflection, but then that’s their problem).

Otherwise, at least in C++, you can often bypass the private specifier without much difficulty. Perhaps the laziest and easiest way to do so is

    #define private public
    #include "foo.hpp"
    #undef private

Unexported package symbols do two things:

- when visibility "windows" are created between packages via the "use" mechanism, unexported symbols are excluded.

- unexported symbols require tokens with two colons: you have to write foo::bar, not just foo:bar, to refer to bar if it is unexported from package foo; moreover you must still write foo::bar even if you are using package foo, whereas if it were exported, you would just write bar.

CLOS uses symbols for naming entities like generic functions, classes and slots. It has no additional protection mechanisms beyond what the symbols provide, and symbols are agnostic of classes (and everything/anything else which they name).

The usefulness of public/protected/private is that it provides a way to narrow the surface area through which derived classes can interact with their superclasses. Which is enormously useful from a maintenance perspective.

The place where inheritance is better than composition is where base classes provide partial implementations that are used by derived classes.

     class Foo {
       public:
          void method_A();
 
       protected:
          friend class Bar;
          void method_B();

       protected:
          friend class Baz;
          void method_C();

       private:
          void method_D();
     };

You can do this by inheriting from 2 different pure abstract classes, but that feels much kludgier to me.

Brilliant steve yegge article on the topic.

Wikileaks To Leak 5000 Open Source Java Projects With All That Private/Final Bullshit Removed

On a more serious note. While I can see the reason for private members, the case for private methods has always been much weaker.

Languages like Python don't have keywords but enforce using conventions like underscore and 'dunder', the latter of which is actually enforced using obfuscation. It is extremely helpful to signal to users that they should not be using certain methods or fields. When there are no access modifiers available, we still see teams writing methods like "xyx_UNSAFE" or "abc_DO_NOT_USE". It's ridiculous to me to encode this kind of information like this instead of having first class support in the language.

Access modifiers also tell the compiler or JIT what is safe or unsafe to manipulate. It has implications beyond users, and can be a determining factor when inlining or making other optimizations.

This article is so opinionated (edgy?) that it ends with "Inheritance was a hack in the first place." I think, like all things, we need to consider the broader landscape for object oriented programming instead of just saying these things are irrelevant and absurd and useless.

See also https://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5...

No thanks. And I'll continue using inheritance and composition correctly too.

Composition is great. It's the preferred way.

However, if you take it to the extreme (composition only, never inheritance) you sometimes end up with really weird meaningless objects that have only a single method and a one-to-one relationship with another object.

Private methods are ideal for making those abstractions easier to understand. A private method, therefore, is equivalent to an object that has a one-to-one relationship with another object (it's only composed there) and a single method.

A protected method is similar, but allows whoever subclasses it to replace that single one-to-one "mini object" inside with another one-to-one "mini object".

When used within this mindset, it greatly simplifies code. It lets you simplify a branch that has only a single leaf into something easier to read.

Together with classical refactorings (extract method, move method, extract class), they're a precious tool.

Of course, typing is a consideration as well, but I'm talking exclusively about their role in granularity control.

It is unecessary, but convenient. It can be misused. Composition can also be misused.

A long time ago in Java corp world, teams would create their own integration libraries with suspicious/horrible contracts. Ended up just using Java’s reflection api to update access modifiers to get their shitty library to work until they fix it (months later…).

And if you don't need private then why have public?