Каково обоснование использования спецификации доступа для метода / поля?

Question

В C++ спецификатор доступа для поля или метода основан на его расположении в соответствии с первой ранее объявленной спецификацией доступа:

public:
  int my_public_variable;
private:
  void secretPrivateOperations();
  int internal_counter;

Каково логическое обоснование разработки Java, определяющего доступ путем добавления спецификатора доступа к каждому методу / полю?

public int my_public_variable;
private void secretPrivateOperations();
private int internal_counter;

Answer 1

Чтобы добавить в awksp ответ, давайте рассмотрим короткий пример. Довольно часто у вас есть открытые методы API, реализованные с закрытыми методами, которые вы не хотите показывать. Чаще всего вы хотите, чтобы код этих методов был близок друг к другу, чтобы облегчить чтение кода, а если нет, вот как он может выглядеть:

public:
    void api1() { 
        do_some_stuff();
        private_method();
        some_other_stuff();
    }

   void api2() {
        do_something();
   }

   int api3() {
        int i = a_computation();
        return i + A_CONSTANT;
   }

private:    
   void private_method() {
        do_clever_stuff();
        api1_implementation_details();
   }

Это не здорово читать, private_method далеко не единственный метод, который использует его, api1, Такое публичное / частное разделение кода не имеет никакого логического смысла. Вы хотите, чтобы ваш код был организован по его логике, а не по видимости методов.

Я очень предпочитаю видеть это:

// I can read the whole logic of this method without any clutter
public void api1() { 
   do_some_stuff();
   private_method();
   some_other_stuff();
}

private void private_method() {
   do_clever_stuff();
   api1_implementation_details();
}
// and so on...

Answer 2

Для сравнения:

public:
    T a();
    T b();
    ...
    T z();

против

public:
    T a() {
        <lots of code>
    }
    T b() {
        <lots of code>
    }
protected:
    T c() {
        <more code>
    }
public:
    T d() {
        <more code>
    }

Если вы "исключите" спецификаторы доступа, как это, все может стать довольно неприятным довольно быстро. Да, отступ помогает. Да, у вас есть Ctrl-F. Но все еще может быть много шума для просмотра (например, многотысячные строковые файлы), и необходимость отвлечься от своей задачи, просто искать подобные вещи, вероятно, не поможет производительности.

Java и C++ Java справляется с этим по-разному. Java сохраняет спецификаторы доступа локальными, поэтому для определения области действия достаточно знать, над каким методом вы работаете. C++ объединяет объявления, так что спецификатор доступа может быть "разложен". Это может быть не так хорошо при реализации методов, но в заголовочных файлах оно гораздо лаконичнее, и, возможно, его проще поймать.