Что считается сторонним кодом?

15

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

Пример из PHP:
Если я создаю приложение с использованием Zend Framework, я должен рассматривать библиотеки Zend Framework как сторонний код?

Пример из C #:
если я создаю настольное приложение, должен ли я рассматривать все классы .Net как сторонний код?

Пример из Java:
Должен ли я рассматривать все библиотеки в JDK как сторонние библиотеки?

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

— Songo
источник

8

Может ли нижестоящий избиратель объяснить, почему?

— Сонго

Я слышал о стороннем программном обеспечении, но не о стороннем коде. Большинство третьих лиц не дают вам свой исходный код.

— Тулаинс Кордова

18

Все ваши примеры - сторонний код, но вы не должны писать для них оболочки. Это большие, зрелые проекты со стабильными и хорошо спланированными API.

Необходимость в оболочках - обеспечить слой абстракции между вашим кодом и библиотекой. Эта абстракция нужна вам только тогда, когда вы обнаружите, что библиотека не предоставляет хороших API для конкретной вещи, которую вы делаете. Затем вы можете создать оболочку, чтобы упростить свой собственный код, и скрыть тот факт, что вызовы API неудобны.

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

— М. Дадли
источник

+1 за объяснение того, когда может понадобиться обертка или фасад, если хотите.

— Джошуа Дрейк

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

— Сонго

@Songo: Ваша стратегия тестирования должна заключаться в создании Zend_Mailмакета, который вы передаете Loggerтестируемому объекту. Разве PHP не поддерживает утку? Если это так, разве не должно быть тривиально создать фиктивный объект ...? Я действительно не знаю PHP, но вы могли бы посмотреть на примеры из библиотек насмешек PHP, чтобы увидеть, как это обычно делается. В языках, которые не поддерживают утиную типизацию, тогда я думаю, что вам нужно будет перейти Zend_Mailна интерфейс, а затем создать тонкую оболочку, которая реализует интерфейс и наследует Zend_Mailили просто делегирует все его вызовы.

— М. Дадли

@emddudley хорошо, да, но я искал более общее решение проблемы на других языках, которые не поддерживают утку. На самом деле ваше решение обернуть Zend_Mailбыло моей первой мыслью, но, как вы можете видеть из моего первоначального поста перед его редактированием, я использовал интерфейс и упаковщик, который его реализует. Тем не менее, единственная цель обертки для существования заключается в том, чтобы я мог высмеивать его интерфейс. Это распространено в языках, которые не поддерживают типизацию утки? Строить бесконечное количество фантиков?

— Сонго

@ Сонго: Я думаю, что это очень зависит от языка и библиотеки, и вы должны делать то, что поддерживает ваша платформа. Иногда вы можете застревать с написанием оберток. Внедрение зависимостей и моделирование объектов - довольно недавние разработки (2004?), Поэтому не все языки и библиотеки поддерживают их очень хорошо. «Общее решение», которое вы ищете, - это просто мышление: как вы можете создать свой код для слабой связи и эффективного модульного тестирования?

— М. Дадли

6

Цель обертывания библиотеки - устранить зависимость вашего кода от этой библиотеки, чтобы включить:

Модульное тестирование - вы должны быть в состоянии протестировать свой код. Если библиотека не позволяет вам высмеивать классы или форсировать ответы, которые вам нужны для теста, то вам нужно обернуть эту библиотеку. Это очевидная проблема, и, вероятно, не тот, который вас интересует.
Изменение реализаций. Как автору кода, вы должны понимать, какие изменения могут произойти, и сколько будут стоить эти изменения по сравнению с вероятностью их возникновения. Можете ли вы перейти с .NET на JVM? Это сложно и маловероятно; тем не менее, в будущем вы, скорее всего, измените технологии пользовательского интерфейса или механизмы XML.

Изоляция сторонних библиотек и фреймворков - это лишь часть изоляции изменений.

— Бен
источник

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

— Серхио Акоста,

2

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

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

— Уайетт Барнетт
источник

2

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

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

Принимая ваш пример, я бы посчитал Zend третьей стороной. Я также построил бы свое приложение таким образом, чтобы моя основная бизнес-логика не зависела от Zend.

Википедия определяет сторонний компонент как:

В компьютерном программировании сторонний программный компонент представляет собой программный компонент многократного использования, разработанный для свободного распространения или продажи компанией, не являющейся первоначальным поставщиком платформы разработки.

— Паткос Чаба
источник

1

В самом строгом смысле каждый приведенный вами пример является сторонним кодом. Однако не весь сторонний код должен быть упакован. Все сторонние библиотеки должны быть упакованы. Фреймворки, по определению, нельзя обернуть, потому что они становятся неотъемлемой частью вашего кода. Вот почему вы должны обернуть свою библиотеку журналов, но не .NET Framework или Zend Framework. Вы не можете отделить ваш код от .NET - они переплетены. Конечно, хорошие фреймворки будут иметь интерфейсы для программирования, что позволит вам в некоторой степени обойти проблему.

— Майкл
источник