Що є загальним способом обробки видимості в бібліотеках?

Це питання про те, коли використовувати приватні та коли використовувати захищені в класах, змусило мене задуматися. (Я поширю це питання також на заключні класи та методи, оскільки це пов'язано. Я програмую на Java, але думаю, що це стосується кожної мови OOP)

Прийнята відповідь говорить:

Добре правило: зробити все максимально приватним.

І ще один:

1. Зробіть усі класи остаточними, якщо вам не потрібно відразу підкласифікувати їх.
2. Зробіть усі методи остаточними, якщо вам не потрібно відразу підкласифікувати їх і замінити.
3. Зробіть усі параметри методу остаточними, якщо вам не потрібно їх змінювати в тілі методу, який у будь-якому разі є незручним у більшості випадків.

Це досить просто і зрозуміло, але що робити, якщо я в основному пишу бібліотеки (Open Source на GitHub) замість програм?

Я міг би назвати багато бібліотек та ситуацій, де

• Бібліотеку розширюють таким чином, про який розробники ніколи не думали б
• Це довелося робити з "магією завантажувача класу" та іншими хаками через обмеження видимості
• Бібліотеки звикли таким чином, щоб вони не були побудовані, і необхідний функціональний спосіб "зламався"
• Бібліотеки не можна було використовувати через невелику проблему (помилка, відсутність функціональності, "неправильна" поведінка), яку не вдалося змінити через зменшену видимість
• Проблема, яку не вдалося виправити, призвела до величезних, потворних і невдалих способів вирішення проблеми, коли переосмислення простої функції (приватної чи остаточної) могло б допомогти

І я насправді почав називати їх, поки питання не стало занадто довгим, і я вирішив їх усунути.

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

Оскільки великі бібліотеки з відкритим кодом - це не нова річ, який найпоширеніший спосіб обробки видимості в таких проектах об'єктно-орієнтованими мовами?

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

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

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

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

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

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

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

Кожен відкритий і розширюваний клас / метод - це частина вашого API, яку потрібно підтримувати. Обмеження цього набору розумним набором бібліотеки дозволяє забезпечити найбільшу стабільність і обмежує кількість речей, які можуть піти не так. Це рішення управління (і навіть проекти OSS керуються певною мірою) на основі того, що ви можете розумно підтримати.

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

• Списки розсилки обговорюють потреби користувача та способи їх здійснення
• Системи відстеження випусків (проблеми JIRA або Git тощо) відслідковують помилки та запити на функції
• Контроль версій управляє вихідним кодом.

У зрілих проектах те, що ви побачите, є чимось таким чином:

1. Хтось хоче зробити щось із бібліотекою, яку вона спочатку не була створена
2. Вони додають квиток до відстеження проблем
3. Команда може обговорити це питання у списку розсилки чи у коментарях, а запитуючий завжди запрошений приєднатися до дискусії
4. Зміна API приймається та визначається пріоритетом або відхиляється з якоїсь причини

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

Жоден API не є статичним. Однак зростання має бути певним чином формуватися. Тримаючи все закритим до тих пір, поки не буде продемонстрована потреба відкривати речі, ви уникаєте отримання репутації баггі чи нестабільної бібліотеки.

Я переформулюю свою відповідь, оскільки, здається, вона вразила нерв у кількох людей.

Властивість / метод видимості класу не має нічого спільного ні з безпекою, ні з відкритістю джерела.

Причина того, що видимість існує, полягає в тому, що об’єкти неміцні до 4 конкретних проблем:

1. одночасність

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

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

2. Допоможіть перешкодити користувачам стріляти в користування інтерфейсом. По суті, це допомагає вам контролювати інваріанти об’єкта.

У кожному об'єкті є маса речей, які потрібно мати істину, щоб бути в послідовному стані. На жаль, ці речі живуть у видимому для клієнта просторі, оскільки дорого переносити кожен об'єкт у свій процес і спілкуватися з ним через повідомлення. Це означає, що дуже легко об'єкт зламати всю програму, якщо користувач має повну видимість.

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

Ще один приємний приклад, коли ви можете покращити зручність використання своїх модулів - це зробити конструктор приватним; тому що якщо конструктор кине виняток, він вб'є програму. Один із ледачих підходів до вирішення цього питання - змусити конструктор викинути помилку часу компіляції, що ви не можете його сконструювати, якщо це не в блоці спробу / лову. Зробивши приватний конструктор і додавши загальнодоступний метод статичного створення, ви можете мати метод створення методу return null, якщо він не зможе його сконструювати, або скористатися функцією зворотного виклику для обробки помилки, зробивши програму більш зручною для користувачів.

3. Область забруднення

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

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

4. прив’язаність до залежностей

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

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