Необходимо ли перенести сторонние библиотеки, которые Вы принимаете в свой проект? [закрытый]

You should do it always, often, sometimes, rarely, or never. Not even your colleague does it always, but the instructive cases are always and never. Suppose that it is sometimes necessary. If you never wrapped a library, the worst consequence is that one day you discovered that it was necessary for a library that you had used all over the place. It would take you some time to wrap that library and to perform shotgun surgery on the clients. The question is whether that eventuality would take more time than habitually providing wrappers that are rarely necessary, but having never to perform the shotgun surgery.

My instinct is to appeal to the YAGNI (you ain't gonna need it) principle and opt for "rarely".

Обертывание всей библиотеки шаблонным, неэффективным и неправильным в большинстве случаев. Это можно сделать очень умно. Я бы сказал, что упаковка библиотеки уместна в основном в случае библиотек компонентов пользовательского интерфейса, и, опять же, вы должны добавить некоторые дополнительные основные свои функции ко всем компонентам, чтобы это было необходимо.

• если требуется слишком много модификаций и дополнений, скорее всего, это не та библиотека, которую вы ищете
• , если есть умеренное количество дополнений и модификаций - всегда есть шаблоны проектирования, которые пригодятся в таких случаях. Шаблон декоратора (позволяет динамически добавлять новое / дополнительное поведение к существующему объекту), например, вполне подходит для большинства случаев.
• Возможности поиска / замены и рефакторинга IDE предлагают простой способ чтобы изменить код во всех необходимых местах, если требуется какое-то важное изменение и появляется объект-оболочка. (конечно, здесь могут быть полезны юнит-тесты;))

Есть одна ситуация, в которой вы по уважительной причине можете обернуть. А именно, если вам нужно протестировать материал, а сторонний объект по умолчанию имеет большой вес. Тогда наличие интерфейса действительно может иметь значение.

Обратите внимание, это не для замены библиотеки, а для того, чтобы сделать ее управляемой там, где это не имеет большого значения.

Это забавный вопрос.

Я работал в системах, где мы обнаружили ошибки showstopper в библиотеках, которые мы использовали, и которые в апстриме либо больше не поддерживались, либо не были заинтересованы в исправлении. На таком языке, как Java, вы обычно не можете исправить внутренние ошибки с помощью оболочки. (К счастью, если они с открытым исходным кодом, вы можете по крайней мере исправить их самостоятельно.) Так что здесь нет никакой помощи.

Но я часто работаю с языком, на котором вы можете легко изменять библиотеки в любое время, не видя или даже имея их исходный код - например, я обычно добавляю новые методы к существующим классам. Так что в этом случае нет смысла оборачиваться: просто внесите нужные изменения.

Кроме того, ваш коллега проводит черту в том, что называется «библиотеками»? А как насчет самой Java? Заворачивает ли он встроенные классы? Он оборачивает файловую систему? Планировщик потоков? Ядро? (То есть с его собственными оболочками - в некотором смысле все является оболочкой вокруг ЦП, но похоже, что он говорит об оболочках в вашем репозитории исходного кода, которые полностью находятся под вашим контролем.) Я ' Встроенная функциональность менялась или пропадала при появлении новых версий. Java не застрахован от этого.

Так что идея всегда писать оболочку сводится к пари. Предполагая, что он упаковывает только сторонние библиотеки, он, кажется, неявно делает ставку на то, что:

• «собственные» функции (например, сама Java, ядро ​​и т. Д.) Никогда не изменятся
• , когда «сторонние» функциональность изменяется, это всегда будет сделано способом, который можно исправить в оболочке

Верно ли это в вашем случае? Я не знаю. Из средних и крупных Java-проектов, которые я делал, для меня это редко бывает правдой. Я бы не стал тратить силы на упаковку всех сторонних библиотек, потому что это кажется плохой ставкой, но ваша ситуация определенно отличается от моей.

Целью создания оболочки даже для хорошо протестированной и проверенной временем сторонней библиотеки является то, что вы можете решить переключить библиотеки в какой-то момент в будущем. Обертывание упрощает переключение без изменения кода в вашем основном приложении. Необходимо изменить только оболочку.

Если вы абсолютно уверены , что никогда (еще одно абсолютное) не будете использовать другую структуру ведения журнала в своем проекте, пропустите оболочку. Даже сказав это, я бы, вероятно, отложил написание оболочки, пока не узнал , что она мне нужна, как в первый раз, когда мне нужно переключиться.

Я бы не оборачивал это как однозначно, но я бы наслаивал приложение так, чтобы каждую часть его можно было заменять как можно больше. Модель ISO OSI хорошо работает для всех типов программного обеспечения: -)

Я склонен согласиться с большинством ваших пунктов. Использование абсолютов часто приводит к неприятностям, а призыв «всегда» делать что-то ограничивает вашу гибкость. Я бы добавил еще несколько пунктов в ваш список.

Когда вы используете код-оболочку для очень распространенного API, такого как Hibernate или log4j, вам становится труднее привлекать новых разработчиков. Новые разработчики теперь должны изучить совершенно новый API, где, если бы вы не обернули код, они были бы очень знакомы сразу.

С другой стороны, вы также ограничиваете взгляд ваших разработчиков на API. Использование расширенной функции API требует больше времени, потому что вы должны убедиться, что ваша оболочка реализована таким образом, чтобы с ней справиться.

Многие из слоев оболочки I ' Мы видели также очень специфичны для базовой реализации. Итак, если вы пишете оболочку журнала для log4j, вы думаете в терминах log4j. Если появится какая-нибудь новая классная структура, это может изменить всю парадигму, поэтому ваш код упаковки не будет мигрировать так хорошо, как вы думали.

Я определенно не говорю, что код упаковки всегда плох, но, как вы сказали, необходимо учитывать множество факторов.

1. Любая неуверенность в выборе сторонней библиотеки должна быть устранена в начале проекта с использованием прототипов для проверки масштабируемости / пригодности / чего-либо еще из сторонней библиотеки.

2. Если вы решите продолжить и предоставить полную поддержка разъединения / абстракции, она должна быть рассчитана и в конечном итоге одобрена спонсором проекта - в конечном итоге это коммерческое решение, поскольку кто-то должен заплатить за него и работу, необходимую для его выполнения (если это не совсем тривиально, и в этом случае вероятно, в любом случае низкий риск).

3. Как правило, опытный архитектор выбирает технологию, в которой он может быть достаточно уверен и иметь опыт, и в которой, как он уверен, прослужит весь срок службы приложения, ИЛИ в противном случае он устранит любой риск при принятии решения на ранней стадии. проект, тем самым устраняя необходимость в этом, в большинстве случаев

Основным фактором для принятия решения о переносе библиотеки в оболочку является влияние изменения библиотеки на код. Когда библиотека вызывается только из 1 класса, влияние изменения библиотеки будет минимальным. Если с другой стороны, библиотека вызывается во всех классах, гораздо более вероятно, что оболочка.

Если библиотека, которую вы планируете обернуть, уникальна по своим «принципам доступа, метафорам и идиомам» из других предложений в том же домене, то ваша оболочка в значительной степени будет похожа на ту. библиотека и не принесет вам никакой пользы, если вы однажды переключитесь на другую библиотеку, поскольку вам понадобится новая оболочка.

Если к библиотеке обращаются так же, как и к другим библиотекам, и та же оболочка может применяться к этим библиотекам , то они, вероятно, написаны на основе какого-то существующего стандарта, и уже существует некий общий уровень для доступа к ним обоим.

Я бы пошел с оболочками, только если бы я точно знал, что мне придется поддерживать несколько и существенно разных библиотеки в производстве.

Проблема здесь частично заключается в слове «оболочка», частично в ложной дихотомии, а частично в ложном различии между JDK и всем остальным.

Слово «оболочка»

Упаковка весь Hibernate, как вы говорите, является совершенно непрактичным предприятием.

С другой стороны, ограничение зависимостей Hibernate идентифицированным, контролируемым набором исходных файлов может быть практичным и дать те же результаты.

Ложная дихотомия

Ложная дихотомия - это неспособность признать третий вариант: стандарты. Если вы используете, скажем, аннотации JPA, вы можете заменить Hibernate на другие вещи. Если вы пишете веб-службу и используете аннотации JAX-WS и JAX-B, вы можете переключаться между JDK, CXF, Glassfish или чем-то еще.

Ложное различие

Конечно, JDK меняется медленно и маловероятно умереть. Но основные пакеты с открытым исходным кодом также медленно меняются и вряд ли умрут. Бесчисленные тысячи разработчиков и проектов используют Hibernate. На самом деле риск исчезновения Hibernate или внесения радикальных несовместимых изменений в API не больше, чем для самой Java.

Что ж, очевидное преимущество заключается в технологиях переключения. Если у вас есть библиотека, которая устарела, и вы хотите переключиться, вы можете в конечном итоге переписать много кода, чтобы учесть это изменение, тогда как если бы она была обернута, вам было бы легче написать новую оболочку для новой библиотеки , чем изменение всего вашего кода.

С другой стороны, это будет означать, что вам придется написать оболочку для каждой тривиальной библиотеки, которую вы включаете, что, вероятно, является недопустимым количеством накладных расходов.

Моя отрасль - это все о скорость, поэтому единственный раз, когда я смогу оправдать написание оболочки, это если бы она была связана с какой-то важной библиотекой, которая, вероятно, будет кардинально меняться на регулярной основе. Или, что еще чаще, если мне нужно взять новую библиотеку и втиснуть ее в старый код, что является печальной реальностью.

Это ' Это определенно не «всегда» ситуация. Это может быть желательно. Но время не всегда будет, и, в конце концов, если написание оболочки займет часы, а долгосрочные изменения библиотеки кода будут небольшими и тривиальными ... Зачем беспокоиться?

Нет. Java-архитекторы / «пчелы-пчелы» слишком заняты проектированием вопреки воображаемым изменениям.

В современной среде IDE это просто кусок пирога, когда вам действительно нужны изменения. А пока не усложняйте.

Я согласен со всем, что было сказано в значительной степени.

Обертывание стороннего кода полезно (нарушает YAGNI) только для модульного тестирования.

Мокинг статики и т. Д. Требует, чтобы вы обернули код, это веская причина для написания оболочек для стороннего кода.

В случае кода журналирования это не требуется.