Інтерфейс і треті особи
Розробник завжди повинен використовувати інтерфейси, а користувач зобов’язаний взаємодіяти з кодом тільки через суворі контракти. Наприклад, в бібліотеці jcabi-github клас RtGithub si єдиний, який він бачить.
Наведений вище фрагмент створює заявку в репозиторії eugenp/tutorials. Примірники Repo і Issue застосовуються, але фактичні типи ніколи не розкриваються. Сценарій, наведений вище, може бути дозволений, але тоді розроблений алгоритм буде забруднена великою кількістю стандартного коду.
Інтерфейси також забезпечують простоту розширення і зворотної сумісності. З одного боку розробники зобов’язані дотримуватися вже випущені контракти, а з іншого – користувач розширює пропоновані інтерфейси: він може їх прикрашати або писати альтернативні реалізації.
Хороша бібліотека – легка. Код повинен вирішити проблему і бути функціональним. Якщо потрібно багато залежностей. Ймовірно, розробник намагається охопити занадто велику кількість функцій і повинен розбити проект на кілька малих.
Проект повинен бути максимально прозорим. Найкращий приклад – використовувати SLF4J з API для ведення журналу. Не варто застосовувати log4j безпосередньо, можливо, розробник захоче застосувати інші засоби ведення журналу.
Підключення Java-бібліотек документів, які переходять через проект транзитивно, виконують, щоб не включалися небезпечні залежності, такі як xalan або xml-apis.
У світі існує сотні тисяч бібліотек, але програмістам потрібно знання лише невеликої кількості найбільш функціональних модулів.
