Используется ли термин, когда внутренние переменные объявлены общедоступными и доступными?

Если кто-то пишет код так, чтобы внутренняя переменная $ _fields была доступна без использования методов получения / установки, существует ли подходящий термин для описания этого?

Что-то достаточно вежливое, чтобы использовать с управлением :)

Разоблачение частных лиц никогда не бывает хорошим делом в вежливом обществе ...

Эта практика заключается в отсутствии / плохой инкапсуляции.

Помимо отсутствия инкапсуляции, уже упомянутого Одедом, в зависимости от языка программирования и его парадигм, это также могут быть «простые старые данные» (где они не обязательно являются антипаттерном или запахом кода).

Я слышал термин «голый предмет» раньше.

Его называют имущественной сумкой.

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

Это называется "не следовать определенному стандарту кодирования".

ОП написал:

внутренняя переменная $ _fields доступна без использования методов получения / установки

Это может быть против вашего стандарта, и (таким образом) это может быть запах кода. Но это не обязательно плохая инкапсуляция. Выставление внутренней (как в «только для внутреннего использования») переменной через getter и setters для внешнего мира было бы еще хуже.

Вопрос: должен ли $_fieldsбыть доступен внешний мир?

Если это так, у нас есть случай, когда вы добавите методы получения / установки. Эти методы не содержат ничего, кроме того факта, что $_fieldsэто какая-то переменная (в отличие от чего-то, вычисленного / извлеченного / и т. Д. На лету). В зависимости от языка, вы, вероятно, все еще будете просачивать тип (он же деталь реализации) наружу. Независимо от того, хотите ли вы всегда получать или устанавливать, или только когда «необходимо» - это стандартная проблема кодирования.

Если не$_fields должен быть доступно, тогда, ну, не получайте к нему доступ. Независимо от того, хотите ли вы запретить другим доступ к нему на уровне языка (частный и друзья) или нет (что может облегчить отладку в определенных обстоятельствах), опять же, это стандартная проблема кодирования.

Проблема инкапсуляции полностью ортогональна этому. Нарушение инкапсуляции абсолютно возможно с геттерами и сеттерами. В это даже легче проникнуть, потому что звонки большинства людей не звонят, когда они видят группу получателей и установщиков - код, который, по-видимому, следует передовым методам. Код, который может очень хорошо вводить гораздо больше зависимостей от внутренних деталей реализации, чем вызываемая переменная, $_fieldsкоторая не указывается как private.

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

Я бы назвал такие переменные открытыми переменными-членами .

если ваши методы setter / getter не более чем

void setfoo(bar){foo=bar;}
foo getfoo{return foo;}

тогда просто создание публичной переменной - это просто сохранение некоторой типизации за пределами нескольких крайних случаев, когда разница имеет значение.