Чому Clean Code пропонує уникати захищених змінних?

Чистий код пропонує уникати захищених змінних у розділі "Вертикальна відстань" розділу "Форматування":

Концепції, які тісно пов'язані між собою, повинні триматися вертикально близько один до одного. Зрозуміло, що це правило не працює для понять, що належать до окремих файлів. Але тоді тісно пов’язані поняття не слід розділяти на різні файли, якщо у вас немає дуже вагомих причин. Дійсно, це одна з причин того, що слід уникати захищених змінних .

Яке міркування?

Захищених змінних слід уникати, оскільки:

1. Вони, як правило, призводять до проблем YAGNI . Якщо у вас є клас нащадків, який насправді робить речі із захищеним членом, зробіть його приватним.
2. Вони, як правило, призводять до проблем LSP . Захищені змінні, як правило, мають деяку внутрішню інваріантність, пов'язану з ними (інакше вони будуть загальнодоступними). Тоді спадкоємцям потрібно підтримувати ті властивості, які люди можуть викрутити або навмисно порушити.
3. Вони схильні порушувати OCP . Якщо базовий клас робить занадто багато припущень щодо захищеного члена або спадкодавець занадто гнучкий у поведінці класу, це може призвести до зміни поведінки базового класу цим розширенням.
4. Вони, як правило, призводять до спадкування для розширення, а не до складу. Це, як правило, призводить до більш жорсткої зв'язку, більшої кількості порушень СРП , більш складного тестування та ряду інших речей, що підпадають під обговорення "складу прихильності над спадщиною".

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

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

Я не читав книгу, але можу сказати, що мав на увазі дядько Боб.

Якщо ви protectedщось одягнете, це означає, що клас може це успадкувати. Але змінні члена повинні належати до класу, в якому вони містяться; це частина базової інкапсуляції. Введення protectedзмінної члена перериває інкапсуляцію, оскільки тепер похідний клас має доступ до деталей реалізації базового класу. Це та сама проблема, яка виникає, коли ви робите змінну publicна звичайному класі.

Щоб виправити проблему, ви можете інкапсулювати змінну в захищеній властивості, наприклад:

protected string Name
{
    get { return name; }
    private set { name = value; }
}

Це дозволяє nameбезпечно встановити з похідного класу за допомогою аргументу конструктора, не піддаючи деталі реалізації базового класу.

Аргумент дядька Боба - це насамперед відстань: якщо у вас є концепція, важлива для класу, зв’яжіть цю концепцію разом із класом у цьому файлі. Не розділено на два файли на диску.

Змінні захищених членів розкидані в двох місцях і, схоже, схожі на магію. Ви посилання на цю змінну, але вона не визначена тут ... де це вона визначається? І таким чином починається полювання. Краще protectedвзагалі уникати його аргументу.

Тепер я не вірю, що правилу потрібно дотримуватися цього листа весь час (наприклад: ти не будеш користуватися protected). Подивіться на дух того, що він отримує при ... поєднанні речей разом в один файл - використовуйте методи програмування та функції для цього. Я рекомендую вам не надто аналізувати і не зациклюватися на деталях цього питання.

Деякі дуже хороші відповіді вже тут. Але додати одне:

У більшості сучасних мов OO є доброю звичкою (у Java AFAIK це необхідно) класти кожен клас у свій власний файл (будь ласка, не розумійте C ++, де у вас часто є два файли).

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

Основна ідея полягає в тому, що "поле" (змінна на рівні екземпляра), яке оголошується захищеним, ймовірно, більш видиме, ніж воно повинно бути, і менш "захищене", ніж ви могли б хотіти. У C / C ++ / Java / C # немає модифікатора доступу, який є еквівалентом "доступного лише дочірнім класам в межах однієї збірки", таким чином, ви надаєте можливість визначати своїх власних дітей, які можуть отримати доступ до поля у вашій збірці, але не дозволяти дітям, створеним в інших зборах, однакового доступу; C # має внутрішні та захищені модифікатори, але їх поєднання робить доступ "внутрішнім або захищеним", а не "внутрішнім і захищеним". Отже, поле, яке захищається, є доступним для будь-якої дитини, незалежно від того, написали ви цю дитину чи хтось інший. Таким чином, захищеними є відкриті двері для хакера.

Крім того, поля за їх визначенням майже не мають валідації, властивої їх зміні. у C # ви можете зробити одне лише повторне читання, що робить типи значень фактично постійними, а типи посилань неможливо повторно ініціалізувати (але все-таки дуже мінливі), але це про це. Як такі, навіть захищені, ваші діти (яким ви не можете довіряти) мають доступ до цього поля і можуть встановити його на щось недійсне, що робить стан об'єкта непослідовним (чого слід уникати).

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

Ще один підхід, який відповідає на питання, - це запитати себе; Чому код у дочірньому методі потребує можливості безпосередньо змінювати мої дані про стан? Що це говорить про цей код? Це аргумент "вертикальної відстані" на його обличчі. Якщо у дитини є код, який повинен безпосередньо змінювати стан батьків, то, можливо, цей код повинен належати в першу чергу батьків?

Це цікава дискусія.

Якщо чесно кажучи, хороші інструменти можуть пом’якшити багато з цих «вертикальних» питань. Насправді, на мій погляд, поняття "файл" насправді є тим, що перешкоджає розробці програмного забезпечення - над тим, що працює над проектом Light Table (http://www.chris-granger.com/2012/04/12/light- таблиця --- a-new-ide-concept /).

Виймайте файли із зображення, а захищена область стає набагато привабливішою. Захищена концепція стає найбільш зрозумілою в таких мовах, як SmallTalk - де будь-яка спадщина просто розширює оригінальну концепцію класу. Він повинен робити все і мати все, що робив батьківський клас.

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

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

Як там сказано, це лише одна з причин, тобто логічно пов'язаний код повинен розміщуватися всередині фізично пов'язаних об'єктів (файлів, пакетів та інших). У меншому масштабі це те саме, що ви не ставите клас, який робить запити БД всередині пакета з класами, що відображають інтерфейс користувача.

Однак головна причина, що захищені змінні не рекомендуються, полягає в тому, що вони, як правило, порушують інкапсуляцію. Змінні та методи повинні мати максимально обмежену видимість; для подальшого ознайомлення див. Ефективну Java Джошуа Блоха , пункт 13 - "Мінімізуйте доступність класів та членів".

Однак ви не повинні сприймати весь цей рекламний літтерам, лише як лінію гільдії; якби захищені змінні дуже погані, вони не були б розміщені всередині мови в першу чергу. Розумне місце для захищених полів imho знаходиться всередині базового класу з тестової системи (інтеграційні тестові класи поширюють його).

Я вважаю, що використання захищених змінних для тестів JUnit може бути корисним. Якщо ви зробите їх приватними, ви не можете отримати доступ до них під час тестування без роздумів. Це може бути корисно, якщо ви протестуєте складний процес через багато змін стану.

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

Так, я погоджуюсь, що дещо дивно, враховуючи, що (як я пам’ятаю) книга також обговорює всі неприватні змінні як щось, чого слід уникати.

Я думаю, що проблема із захищеним модифікатором полягає в тому, що не тільки учасник піддається підкласам, але і стає видимим для всього пакету. Я думаю, що саме цей подвійний аспект дядько Боб приймає тут виключення. Звичайно, не завжди можна обійти захищені методи, а отже, і захищену змінну кваліфікацію.

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