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

10

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

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

Петерб
источник
9
Недостаток инкапсуляции?
Одед
@ Оде я думаю, что вы правы - отсутствие / плохая инкапсуляция хорошо это описывает
PeterB
Две фразы, о которых я подумал, пытаясь ответить на этот вопрос, были «дырявая абстракция» и «свободная область видимости» - к чему относится каждая из них (вне моей головы)?
PeterB
1
Утечка абстракции - это когда вы пытаетесь абстрагировать концепцию, но она на самом деле не работает - лежащие в основе концепции все еще просачиваются (ORM в SQL и веб-фреймворки через HTTP / HTML, как правило, являются утечками абстракций).
Одед
@PeterB - чтобы добавить к объяснению Одеда, смотрите это: joelonsoftware.com/articles/LeakyAbstractions.html
Joris Timmermans

Ответы:

30

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

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

Одед
источник
6
+1, ну вы бы не вывели своих рядовых в офис, не так ли?
StuperUser
6
-1: Инкапсуляция действительно произошла и прошла хорошо. Но это не было задокументировано через исходный код общепринятым способом. В некоторых языках (например, Python) отсутствуют действительно закрытые переменные, но они все еще практикуют инкапсуляцию.
S.Lott
6
@Oded: Инкапсуляция - это концепция дизайна . Разные языки имеют разные реализации концепции. Язык с частным объявлением допускает одну реализацию. Функциональный язык программирования с объектами без сохранения состояния может иметь другую реализацию. В Python (которого нет private) есть еще одна реализация концепции инкапсуляции.
S.Lott
1
@ S Lott; Одед - инкапсуляция хороша, и полагаться на код, где частные переменные часто напрямую доступны из других классов, плохая инкапсуляция. В python вы делаете это, обращаясь к закрытым переменным именам другого класса или игнорируя соглашения с одним префиксом подчеркивания (хотя, если ваш метод получения выполняет другое поведение; в действительности следует использовать __для искажения имен). Другие языки также могут иметь плохую инкапсуляцию, например, отражение в Java и арифметику указателей в C ++ для доступа к закрытым переменным. Python просто не делает синтаксис, чтобы сделать это настолько громоздким.
Доктор Джимбоб
2
@drjimbob: код Python редко использует __искажение имен. Без __этого дизайн по-прежнему отражает хорошую инкапсуляцию. Утверждать, что «public» означает «отсутствие / плохая инкапсуляция», неправильно. Концепция все еще присутствует. В исходном коде отсутствует соответствующее оформление.
С.Лотт
10

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

Йорис Тиммерманс
источник
4

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

Рака
источник
1
Это, безусловно, сбивает с толку способ назвать тех, кто рассматривает модель обнаженных объектов
Матье
1
Да, это меня и смутило.
Раку
2

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

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

Мартин Йорк
источник
2

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

ОП написал:

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

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

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

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

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

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

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

rwos
источник
1

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

Оливье Жако-Дескомб
источник
-2

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

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

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

Ryathal
источник
3
То, что сейчас все, что делают ваши геттеры и сеттеры, не означает, что так будет всегда. И если добавление проверки к установщику требует прохождения десятков тысяч строк кода, чтобы найти везде, где осуществляется доступ к этому свойству, вы мгновенно потеряете дюжину секунд, которые вы сэкономили, преднамеренно избегая инкапсуляции в первый раз.
Plutor
@Plutor: Если это все, что объект когда-либо сделает (например, потому что он представляет сообщение, отправленное другому процессу или запись в базе данных), тогда все в порядке; это вещи, которые должны быть высоко сохранены.
Donal Fellows