разрешает прямой доступ к переменным члена класса извне класса?

Question

Дан следующий класс:

class ToggleOutput {

  public:
    uint32_t count;
    ToggleOutput(PARAMETERS) //I've just removed stuff to reduce the code
    {
      // The code when setting things up
    }

    void Update()  // public method to toggle a state
    {
        // this method will check if a time period has elapsed
        // if the time period has elapsed, toggle an output
        // Each time the output is toggled on then count gets incremented

        count += 1;
     }
};

Позже в коде создается несколько экземпляров ToggleOutput

ToggleOutput outPut_1(PARAMETERS); // Again, PARAMETERS are just the stuff 
ToggleOutput outPut_2(PARAMETERS); // I've cut out for brevity.
ToggleOutput outPut_3(PARAMETERS);
ToggleOutput outPut_4(PARAMETERS); 

во время выполнения я хочу делать вещи, основываясь на значении переменной члена класса, count. например,

if (outPut_1.count >= SOMEVALUE)
  do_some_stuff();

Мне сказали, что это неприемлемо. Чтобы следовать «принципам ООП», методы класса должны быть реализованы для взаимодействия с переменными класса извне класса, например, приведенный выше код должен стать

if (outPut1.getCount() >= SOMEVALUE)

и переменная класса count должна быть сделана закрытой.

Это правда? Или допустимо разрешить прямой доступ к переменным класса, если требуется

Answer 1

По сути, членский доступ - это правило, которое вы навязываете разработчикам.

Это то, что вы создали, чтобы не позволить себе или другому разработчику, использующему ваш класс, изменять свойства, которые должны управляться только самим классом и никем другим.

Это не имеет ничего общего с безопасностью (ну, не обязательно в любом случае), это скорее вопрос семантики. Если он не должен быть изменен извне, он должен быть private.

А почему это должно вас волновать? Что ж, это помогает вам поддерживать целостность и организованность кода, что особенно важно, если вы работаете с командой разработчиков или с кодом, который вы намерены распространять.

И если вам нужно документировать свой класс, вы должны делать это только для вещей, которые public, поскольку пользователь класса ничего не значит.

Answer 2

Или допустимо разрешить прямой доступ к переменным класса, если требуется

много исследований в области хорошей разработки программного обеспечения и производительности труда программистов показывают, что обычно полезно скрывать детали того, как что-то реализовано. Если человек А пишет класс, то у него / нее есть определенные предположения о том, как класс должен работать. Если человек B хочет использовать класс, то у него / нее часто возникают разные предположения о том, как должен работать класс (особенно, если человек A плохо документировал код или даже вообще, как это бывает слишком часто). Тогда человек B может неправильно использовать данные в классе, что может нарушить работу методов класса и привести к ошибкам, которые трудно отладить, по крайней мере, для человека B.

Кроме того, скрывая детали реализации класса, человек А может свободно переделывать реализацию, возможно, удаляя переменную count и заменяя ее чем-то другим. Это может произойти, потому что человек А находит лучший способ реализовать count, или потому что count был там только как инструмент отладки и не нужен для фактической работы ToggleOutput и т. Д.

Программисты не пишут код только для себя. Как правило, они пишут код для других людей, который будет поддерживаться для других людей. «Другие люди» включают вас через пять лет, когда вы смотрите на то, как вы реализовали что-то, и спрашиваете себя: Что, черт возьми, я думал? Сохраняя детали реализации скрытыми (включая данные), которые вы имеете свобода изменять это, и клиентские классы / программное обеспечение не должны волноваться об этом, пока интерфейс остается тем же.