Вдохновленный этим вопросом Использование сторонних библиотек - всегда использовать обертку? Я хотел знать, что люди на самом деле считают сторонними библиотеками.
Пример из PHP:
Если я создаю приложение с использованием Zend Framework, я должен рассматривать библиотеки Zend Framework как сторонний код?
Пример из C #:
если я создаю настольное приложение, должен ли я рассматривать все классы .Net как сторонний код?
Пример из Java:
Должен ли я рассматривать все библиотеки в JDK как сторонние библиотеки?
Некоторые люди говорят, что если библиотека стабильна и не будет часто меняться, то не нужно ее оборачивать. Однако я не вижу, как можно протестировать класс, который зависит от стороннего кода, без его переноса.
Ответы:
Все ваши примеры - сторонний код, но вы не должны писать для них оболочки. Это большие, зрелые проекты со стабильными и хорошо спланированными API.
Необходимость в оболочках - обеспечить слой абстракции между вашим кодом и библиотекой. Эта абстракция нужна вам только тогда, когда вы обнаружите, что библиотека не предоставляет хороших API для конкретной вещи, которую вы делаете. Затем вы можете создать оболочку, чтобы упростить свой собственный код, и скрыть тот факт, что вызовы API неудобны.
Ваш код будет тестируемым, если вы используете внедрение зависимостей. В ваших модульных тестах вы можете поменять зависимость библиотеки с фиктивным объектом, что позволит вам изолировать тестируемый код.
источник
Zend_Mailмакета, который вы передаетеLoggerтестируемому объекту. Разве PHP не поддерживает утку? Если это так, разве не должно быть тривиально создать фиктивный объект ...? Я действительно не знаю PHP, но вы могли бы посмотреть на примеры из библиотек насмешек PHP, чтобы увидеть, как это обычно делается. В языках, которые не поддерживают утиную типизацию, тогда я думаю, что вам нужно будет перейтиZend_Mailна интерфейс, а затем создать тонкую оболочку, которая реализует интерфейс и наследуетZend_Mailили просто делегирует все его вызовы.Zend_Mailбыло моей первой мыслью, но, как вы можете видеть из моего первоначального поста перед его редактированием, я использовал интерфейс и упаковщик, который его реализует. Тем не менее, единственная цель обертки для существования заключается в том, чтобы я мог высмеивать его интерфейс. Это распространено в языках, которые не поддерживают типизацию утки? Строить бесконечное количество фантиков?Цель обертывания библиотеки - устранить зависимость вашего кода от этой библиотеки, чтобы включить:
Изоляция сторонних библиотек и фреймворков - это лишь часть изоляции изменений.
источник
Я бы не стал относиться к членам стандартной библиотеки как к стороннему коду - они все-таки являются стандартными и могут разумно предположить, что они доступны и работают на используемой платформе.
Что касается чего-то вроде Zend, я думаю, что никто бы не обернул это - вам, вероятно, нужно было бы переписать программу, если вы взяли на себя другой фреймворк. Честно говоря, я бы не стал оборачиваться многим, если бы не было серьезной зависимости от внешней конфигурации или если бы я не планировал делать эту часть заменяемой.
источник
Я бы рассматривал библиотеки, предоставляемые конкретным языком программирования, как часть языка.
Тогда я хотел бы рассмотреть сторонние, все библиотеки, предоставляемые любым другим объектом, как расширение или отдельный инструмент от самого языка программирования.
Принимая ваш пример, я бы посчитал Zend третьей стороной. Я также построил бы свое приложение таким образом, чтобы моя основная бизнес-логика не зависела от Zend.
Википедия определяет сторонний компонент как:
источник
В самом строгом смысле каждый приведенный вами пример является сторонним кодом. Однако не весь сторонний код должен быть упакован. Все сторонние библиотеки должны быть упакованы. Фреймворки, по определению, нельзя обернуть, потому что они становятся неотъемлемой частью вашего кода. Вот почему вы должны обернуть свою библиотеку журналов, но не .NET Framework или Zend Framework. Вы не можете отделить ваш код от .NET - они переплетены. Конечно, хорошие фреймворки будут иметь интерфейсы для программирования, что позволит вам в некоторой степени обойти проблему.
Смотрите также: /programming/148747/what-is-the-difference-between-a-framework-and-a-library
источник