Когда, почему и как использовать обертки?

Question

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

Поэтому возник вопрос, зачем вообще использовать обертки.(В прошлом опытные программисты поощряли меня писать обертки для сторонних библиотек.) Я пришел к следующим выводам;пожалуйста, скажите мне, если они не правы или вам есть что добавить.

• Если библиотека не используется широко в приложении (например, используется только одним или двумя классами), не пишитеобертка на всех, просто используйте его напрямую.(Особенно, если это переносимая библиотека.)
• Когда вы пишете обертки, не думайте, что вы можете сделать обертку одного размера для всех.Напишите что-нибудь подходящее для сильных сторон библиотеки.
• ... Но в некоторых случаях вы все равно можете обобщить обертку достаточно, чтобы было легче переключать библиотеки.(Например: большинство графических библиотек используют изображения и шрифты.)
• Оболочки полезны, когда библиотека предлагает больше функций, чем вам нужно.Вы можете скрыть ненужные функции в оболочке.
• В случае библиотек C (если вы используете C ++) вы также можете написать оболочку, которая поможет вам с автоматическим управлением памятью.

Как вы думаете, в чем заключаются (не) преимущества использования упаковщиков, и как их правильно использовать?

Answer 1

Я думаю, что вы ударили ноготь по голове, обертки просто для того, чтобы что-то потенциально могло быть заменено, плохая идея.Классическим примером является база данных, и кому на самом деле когда-либо приходилось переходить с SQL на Oracle (я знаю, что люди это делали, но как часто и действительно ли было полезно иметь обертку?).

По моему опыту, оболочка помогает, только если она скрывает 2+ вызовы стороннего компонента или API-интерфейсы в одном вызове, что что-то значит для вызывающего кода (в основном шаблон фасада) или если он упаковывает код и добавляет преобразование значения / типа для вызывающей стороны ( шаблон адаптера ).

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

Answer 2

«Все проблемы в области компьютерных наук могут быть решены с помощью другого уровня косвенности» Батлер Лэмпсон

В абстрагировании сторонних библиотек стоитсоздание обертки.Вы должны решить, стоит ли стоимость этого или нет.Например, чрезвычайно сложно (или, по крайней мере, связано со значительными затратами на разработку) создать оболочку для наборов инструментов или библиотек пользовательского интерфейса.Напротив, относительно легко создавать оболочки для сторонних библиотек журналов.

Оболочка также может использоваться для обеспечения специфичного для домена и упрощенного API поверх сторонней библиотеки.Шаблон фасада может помочь (как упоминал Пол Хэдфилд).

Answer 3

Упаковщики мощны, если вы хотите проверить в изоляции . Например, моя система разработки не имеет связи с ActiveDirectory моих клиентов, который содержит имена пользователей и роли. поэтому у меня есть UserInfoWrapper-Interface с двумя реализациями: одна, которая использует activedirectory, и другая с поддельными userdata, используемыми для разработки.