Чи використовується термін, коли внутрішні змінні оголошуються загальнодоступними та доступними?

10

Якщо хтось пише код таким чином, щоб внутрішня змінна $ _fields була доступна без використання методів getter / setter, чи є відповідний термін, який використовується для опису цього?

Щось ввічливе для використання з управлінням :)

terminology scope

— PeterB
джерело

9

Відсутність інкапсуляції?

— Одід

@Oded Я думаю, що ти маєш рацію - відсутність / погана інкапсуляція це добре описує

— PeterB

Дві фрази, про які я думав, намагаючись відповісти на це запитання, були "непрохідна абстракція" та "вільне обстеження" - на що посилається кожна з них (поза моєю головою)?

— PeterB

1

Витікаюча абстракція - це коли ви намагаєтесь абстрагувати поняття, але воно насправді не спрацьовує - основні поняття все ще просочуються (ORM-файли через SQL та веб-рамки через HTTP / HTML, як правило, є хиткими абстракціями).

— Одід

@PeterB - щоб додати пояснення Одеда

— Joris Timmermans

30

Викриття приватних членів ніколи не є доброю справою ввічливого суспільства ...

Така практика - відсутність / погана інкапсуляція.

— Одіє
джерело

6

+1, ну ви б не привели своїх приватних осіб в офіс, чи не так?

— StuperUser

6

-1: Інкапсуляція дійсно сталася і сталася добре. Але це не було задокументовано через вихідний код загальноприйнятим способом. Деякі мови (наприклад, Python) не мають справді приватних змінних, але все ще практикують інкапсуляцію.

— С.Лотт

6

@Oded: Інкапсуляція - це концепція дизайну . Різні мови мають різну реалізацію концепції. Мова з приватною декларацією дозволяє одну реалізацію. Функціональна мова програмування з об'єктами без стану може мати іншу реалізацію. Python (якого бракує private) має ще одну реалізацію концепції інкапсуляції.

— S.Lott

1

@S Lott; Oded - інкапсуляція хороша і покладається на код, де приватні змінні часто безпосередньо отримують доступ з інших класів - це погана інкапсуляція. У python ви робите це, отримуючи доступ до приватних змінних, керованих іменами іншого класу, або ігноруючи умовні позначення одного префікса підкреслення (хоча якщо ваш гетьтер виконує іншу поведінку; дійсно слід використовувати __для керування іменами). Інші мови також можуть мати погану інкапсуляцію, наприклад, відображення в Java та арифметична вказівник на C ++, щоб отримати приватні змінні. Python просто не робить синтаксис, щоб зробити це громіздко.

— dr jimbob

2

@drjimbob: Код Python рідко використовує керування __іменами. Без __цього дизайн все ще відображає хорошу інкапсуляцію. Стверджувати, що "громадськість" означає "відсутність / погана інкапсуляція" - неправильно. Концепція все ще присутня. У вихідному коді немає відповідного декору.

— С.Лотт

10

Окрім відсутності інкапсуляції, про яку вже говорив Одєд, залежно від мови програмування та його парадигм це може бути також "простими старими даними" (де це не обов'язково антипатерн або кодовий запах).

— Йоріс Тіммерманс
джерело

4

Я раніше чув термін "голий предмет".

— Раку
джерело

1

Це, безумовно, заплутаний спосіб назвати тих, хто розглядає шаблон

— голих

1

Так, це також мене заплутало.

— Раку

2

Його називають мішком власності.

Зазвичай він використовується для зберігання набору пов'язаних з можливостями властивостей (кожен потенційно може бути об'єктом класу, який має відповідні специфікатори доступу чи ні). Але навколишня структура - лише мішок властивостей.

— Мартін Йорк
джерело

2

Це називається "не дотримання конкретного стандарту кодування".

В ОП написано:

доступна внутрішня змінна $ _fields без використання методів getter / setter

Це може суперечити вашому стандарту, і (таким чином) це може бути запах коду. Але це не обов'язково погана інкапсуляція. Викриття внутрішньої (як у "лише внутрішнього використання") змінної над геттером та сетером зовнішньому світу було б ще гірше.

Питання: чи має $_fieldsбути доступним для зовнішнього світу?

Якщо так, у нас є випадок, коли ви б додали методи getter / setter. Ці методи не інкапсулюють нічого, окрім того, що $_fieldsє певною змінною (на відміну від чогось обчисленого / вилученого / тощо. На льоту). Залежно від мови, ви, ймовірно, все ще будете просочувати тип (він же деталі реалізації) зовні. Незалежно від того, чи завжди ви хочете отримати геттерів / сеттерів, або лише тоді, коли "потрібно", це стандартне питання кодування.

Якщо $_fieldsце не може бути доступним, то, ну, не отримуйте доступу до нього. Незалежно від того, чи варто заважати іншим отримувати доступ до нього на мовному рівні (приватні та друзі) чи ні (що може полегшити налагодження в певних обставинах) - це знову-таки стандартна проблема кодування.

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

Я прихильник поганих аналогій: Називати цю погану інкапсуляцію - це як називати когось, хто тримає пістолет, вбивцею.

— rwos
джерело

1

Я б назвав такі змінні загальнодоступними змінними .

— Олів'є Якот-Дескомб
джерело

-2

якщо ваші методи сеттера / геттера є не що інше

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

то просто створення лобкової змінної - це просто збереження деяких типів тексту за межами кількох крайових випадків, коли різниця має значення.

— Рятал
джерело

3

Тільки тому, що це зараз всі ваші жителі та сетери, це не означає, що так завжди буде. І якщо для додавання валідації до сеттера потрібно прочесати десятки тисяч рядків коду, щоб знайти всюди, до якої можна отримати доступ до власності, ви вмить видувете десятки секунд, які ви зберегли, навмисне уникаючи інкапсуляції вперше.

— Plutor

@Plutor: Якщо це все, що коли-небудь зробить об'єкт (наприклад, тому що він являє собою повідомлення, надіслане іншому процесу або запис у базі даних), тоді це нормально; це речі, які слід дуже зберегти.

— стипендіати