Есть ли веская причина для использования публичной собственности / поля?

Question

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

Примечание. Я использую только термин «свойство» или «поле», поскольку терминология различается в разных языках.В общем, я имею в виду переменную, которая принадлежит объекту, к которому можно получить доступ и установить снаружи объекта.

Answer 1

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

Например, открытые поля являются разумными и полезными для:

• C ++ pimpl - структура / класс, содержащий закрытую реализацию другого класса. Его поля могут быть объявлены публично синтетически, но обычно доступны только в пределах одного исходного файла классом, содержащим pimpl.
• Постоянные поля. Например, Джошуа Блох пишет в Effective Java : «Классам разрешено выставлять константы через открытые статические конечные поля».
• Структуры, используемые для связи между C и C ++.
• Типы, представляющие только данные, представление которых вряд ли изменится. Например, javax.vecmath.Point3d, представляющий координату {x, y, z}.

Answer 2

Краткий ответ: никогда.

На самом деле, если вы используете объект для простого хранения данных, но сам объект не имеет логики, и вы никогда не собираетесь наследовать от этого объекта, тогда все в порядке, чтобы иметьпубличные поля.Иногда я делаю такие вещи в C ++:

struct A {
    int a;
    float b;
    string c;
    A():a(0),b(0.0) {}
    A(int a_, float b_, string c_):a(a_),b(b_),c(c_) {}
};

Но, кроме инициализации конструкторов, это не что иное, как структура C.Если ваш класс делает что-то большее, чем это, вы никогда не должны использовать публичные (или даже защищенные) поля.

Что касается свойств, это зависит от того, какой язык вы используете.Например, в Delphi основное назначение свойств состоит в предоставлении открытых интерфейсов для полей и может предоставлять им методы получения / установки, в то же время синтаксически работая как переменная.

Answer 3

Есть ли веская причина использовать публичное свойство / поле?

Нет.

Публичные члены всегда опасны.Возможно, вам сейчас не нужен контроль, но как только вы их выставите, вы потеряете возможность иметь контроль позже.Если у вас есть gettes / setters сразу, у вас есть место для добавления элемента управления позже.

_{Ps: В зависимости от языка, который вы используете, свойства и поля могут означать разные вещи. C # свойства на самом деле способ достижения инкапсуляции и в то же время не слишком многословный.}

Answer 4

Если целью объекта является хранение данных в его полях, тогда да. Также имеет смысл иметь методы для объекта, которые (а) являются чисто функциональными (в том смысле, что они не изменяют состояние объекта или что-либо еще); или (b) которые манипулируют состоянием объекта, и дело в том, что они манипулируют состоянием определенным образом.

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

Answer 5

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

Во многих языках это также достижимо путем включения метода (ов) доступа.