Как классы более безопасны, чем структуры?

Question

Член структуры по умолчанию открыт, а члены класса по умолчанию закрыты. Мы можем получить доступ к личным данным членов через соответствующий канал (используя функцию-член). Если у нас есть доступ к функциям-членам, мы можем читать / записывать данные в приватных данных-членах, поэтому насколько это безопасно ... мы обращаемся к ним и тоже меняем данные .....

Answer 1

Существует только два синтаксических различия между class и struct:

1. В class члены по умолчанию private, тогда как в struct они public по умолчанию.
2. По историческим причинам class может использоваться вместо typename для объявления параметра типа шаблона.

На самом деле, нет никакой разницы между

struct X {
  void f() {}
private:
  int i;
};

и

class Y {
  int i;
public:
  void f() {}
};

Единственный способ, с помощью которого class является более "безопасным", чем struct, - это то, что он мягко "прижимает" вас к лучшей инкапсуляции, применяя по умолчанию private членов.

В действительности не было необходимости вводить новое ключевое слово class, сам Страуструп говорил это несколько раз. (Прочтите его книгу Дизайн и развитие C ++ , если вы заинтересованы в таких вещах.) В основном, class был введен, чтобы подчеркнуть тот факт, что struct с функциями-членами на самом деле не «структура» больше не так, как термин использовался в C: коллекция слабо связанных объектов встроенных типов. Это «класс» в том смысле, что этот термин используется в статически типизированных объектно-ориентированных языках, даже если синтаксически , это не реальное отличие от struct.

Answer 2

Спецификаторы доступа, такие как private и public, не имеют ничего общего с безопасностью. Например, в C ++ эти спецификации компилируются и даже не существуют в скомпилированном двоичном файле.

Скорее, спецификаторы доступа предназначены для того, чтобы сделать типы простыми в использовании, правильными и трудными в использовании неправильно.

Answer 3

в первую очередь потому, что функции-члены могут проверять значения перед их сохранением. например, скажем, у вас есть поле с именем age, которое должно быть от 0 до 150. В структуре (или классе с открытым полем) вы можете просто сделать obj.age = 200. тогда как если бы у вас был только метод setAge(int), этот метод мог бы проверить, что значение находится в диапазоне от 0 до 150, перед сохранением, возможно, при необходимости, выдавая исключение, или просто ограничивая значение, если нет.

Answer 4

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

Основное отличие состоит в том, что вы контролируете, когда и как изменяются данные вашего класса, и, таким образом, вы можете контролировать свои инварианты классов. Рассмотрим простой векторный класс, который имеет указатель и размер. Имея их в частном порядке, вы можете контролировать их изменение: если вызывается метод resize, указатель и переменная внутреннего размера будут согласованно обновляться, сохраняя инвариант, обеспечивающий доступ к любой позиции в диапазоне [0..size): хорошо определены. Если бы атрибуты-члены были общедоступными, пользовательский код обновлял бы хранилище или размер без фактического обновления другого поля, и этот инвариант мог быть поврежден.

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

Все дело в том, что вы контролируете доступ и изменение ваших членов, что уменьшает количество мест, где могут быть допущены ошибки, и / или ваши шансы обнаружить их.

Answer 5

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