Доступ за замовчуванням не робить модифікатор приватного доступу зайвим.
Позиція мовних дизайнерів щодо цього відображена в офіційному навчальному посібнику - Контроль доступу до членів класу, і це досить зрозуміло (для вашої зручності відповідне твердження в цитаті зроблено жирним шрифтом ):
Поради щодо вибору рівня доступу:
Якщо інші програмісти використовують ваш клас, ви хочете переконатися, що помилки від неправильного використання не можуть трапитися. Рівень доступу може допомогти вам це зробити.
- Використовуйте найбільш обмежуючий рівень доступу, який має сенс для конкретного учасника. Використовуйте приватне, якщо у вас немає вагомих причин цього не робити.
- Уникайте публічних полів, крім констант. (Багато прикладів підручника використовують загальнодоступні поля. Це може допомогти проілюструвати деякі моменти коротко, але не рекомендується для виробничого коду.) Публічні поля, як правило, пов'язують вас із певною реалізацією та обмежують вашу гнучкість у зміні коду.
Ваше звернення до заповідності як виправдання для повного відмови від приватного модифікатора є помилковим, про що свідчать, наприклад, відповіді в Новому до TDD. Чи варто уникати приватних методів зараз?
Звичайно, ви можете мати приватні методи, і звичайно, ви можете їх перевірити.
Або є якийсь - то спосіб , щоб отримати приватний метод для запуску, в цьому випадку ви можете перевірити це , що шлях, чи ні немає способу , щоб отримати приватні бігти, і в цьому випадку: чому, чорт візьми , ви намагаєтеся перевірити це, просто видалити прокляту річ ...
Положення мовних дизайнерів щодо призначення та використання доступу на рівні пакунків пояснено в іншому офіційному посібнику " Створення та використання пакетів", і це не має нічого спільного з ідеєю відмови від приватних модифікаторів (для вашої зручності, відповідне твердження в цитаті зроблено жирним шрифтом ) :
Ви повинні поєднати ці класи та інтерфейс у пакет з кількох причин, включаючи наступне:
- Ви та інші програмісти можете легко визначити, що ці типи пов'язані ...
- Ви можете дозволити типам у пакеті мати необмежений доступ один до одного, але все ще обмежувати доступ для типів поза пакетом ...
<rant "Я думаю, що я почув достатньо скуголення. Зрозуміло, прийшов час сказати голосно і чітко ...">
Приватні методи корисні для одиничного тестування.
Примітка нижче передбачає, що ви знайомі з покриттям коду . Якщо ні, то знайдіть час для вивчення, оскільки це цілком корисно тим, хто цікавиться тестуванням одиниць та взагалі тестуванням.
Гаразд, тому у мене є тест приватного методу та одиниці тестування, і аналіз покриття говорить про те, що існує розрив, мій приватний метод не покривається тестами. Тепер ...
Що я отримую від збереження приватного життя
Оскільки метод є приватним, єдиний спосіб продовжити - вивчити код, щоб дізнатися, як він використовується за допомогою приватного API. Як правило, таке дослідження виявляє, що причиною цього є відсутність конкретного сценарію використання в тестах.
void nonPrivateMethod(boolean condition) {
if (condition) {
privateMethod();
}
// other code...
}
// unit tests don't invoke nonPrivateMethod(true)
// => privateMethod isn't covered.
Для повноти інших (менш частих) причин таких прогалин покриття можуть бути помилки в специфікації / дизайні. Я не занурюватимусь сюди глибоко, щоб все було просто; Досить сказати, що якщо ви послабите обмеження доступу "лише для того, щоб зробити метод тестуваним", ви втратите шанс дізнатися, що ці помилки взагалі існують.
Тонко, щоб виправити розрив, я додаю тестовий блок для відсутнього сценарію, повторюю аналіз покриття та переконуюсь, що розрив зник. Що я маю зараз? У мене є новий тест для специфічного використання не приватного API.
Новий тест гарантує, що очікувана поведінка цього використання не зміниться без попереднього повідомлення, оскільки якщо воно зміниться, тест не вдасться.
Зовнішній читач може заглянути в цей тест і дізнатися, як він повинен використовуватись і поводитися (тут, зовнішній читач включає моє майбутнє «я», оскільки я, як правило, забув код через місяць-два після того, як я з ним закінчуюсь).
Новий тест толерантний до рефакторингу (чи я рефакторні приватні методи? Ти робиш ставку!) Що б я не робив privateMethod, я завжди хочу тестувати nonPrivateMethod(true). Незалежно від того, що я роблю privateMethod, не потрібно буде змінювати тест, оскільки метод не викликається безпосередньо.
Непогано? Будьте впевнені.
Що я втрачаю від ослаблення обмеження доступу
Тепер уявіть, що замість вище, я просто послаблюю обмеження доступу. Я пропускаю вивчення коду, який використовує метод, і переходжу безпосередньо до тесту, який викликає мій exPrivateMethod. Чудово? Ні!
Чи можу я отримати тест на конкретне використання приватного API, згаданого вище? Ні: тестування nonPrivateMethod(true)раніше не було, і такого випробування зараз немає.
Чи отримують зовнішні читачі можливості краще зрозуміти використання класу? Ні. "- Ей, яка мета випробуваного тут методу? - Забудьте це, він суворо для внутрішнього використання. - На жаль."
Чи толерантний до рефакторингу? Ні в якому разі: що б я не змінився exPrivateMethod, це, ймовірно, зламає тест. Перейменуйте, об'єднайтеся в якийсь інший метод, змініть аргументи і тест просто перестане збирати. Головний біль? Будьте впевнені!
Підбиття підсумків , дотримання приватного методу приносить мені корисне, надійне вдосконалення в одиничних тестах. На противагу цьому, ослаблення обмежень доступу "для перевірки" дає мені лише незрозумілий, важко зрозумілий фрагмент тестового коду, який також є постійним ризиком бути порушеним будь-яким незначним рефакторингом; відверто кажучи, те, що я отримую, виглядає підозріло як технічний борг .
</rant>