Api / плагины для библиотек с открытым исходным кодом?

Question

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

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

 $fields = array('name' => 'peter', 'email' => 'peter@gmail.com');
 Doctrine_Facade::create_entity($entity, $fields);

затем создает объект с предоставленной информацией.

так что, я думаю, все кодеры создадут свой собственный "Фасад".

Интересно, как обычно с открытыми фасадами скачивать и взаимодействовать с открытыми библиотеками? это редкая причина, я не видел ничего из этого. в некоторых рамках я видел их, называемые плагинами, например. плагины для Twitter API или Facebook API.

Поэтому, когда вы загружаете библиотеку, вам следует искать плагины / фасады в сети или лучше просто попробовать написать свое собственное? я просто подумал, что было бы здорово, чтобы все не изобретали велосипед.

спасибо.

Answer 1

Допустим, речь идет не только о фабриках, допустим, вы действительно часто пишете Фасады для используемых вами библиотек. Какой смысл? Зачем ты это делаешь? Дело в том, что вы используете библиотеку определенным образом. Если Фасад, который вы пишете, был универсальным, и каждый имел тенденцию писать что-то подобное, Фасад, несомненно, был бы частью библиотеки. Таким образом, причина, по которой это не так и почему вы хотите написать это, заключается в том, что вы используете это очень специфическим образом, который является специфическим для вашего применения библиотеки. Таким образом, вы переходите от абстракции библиотеки к абстракции вашего приложения. Это может устранить большую часть сложности библиотеки из вашего приложения, но также ограничивает способ использования библиотеки. Так что, если вы поняли мою мысль, вы можете быть уверены, что нет смысла выпускать каждый Фасад для определенного способа использования библиотеки. Однако иногда, когда мы говорим о большой влиятельной библиотеке, которая объединяется с некоторыми другими библиотеками и вместе составляет абстракцию, которая может широко использоваться, может случиться, что будет создана новая библиотека.

Answer 2

Цель Фасада - ( цитирование )

• Предоставляет унифицированный интерфейс для набора интерфейсов в подсистеме. Фасад определяет высокоуровневый интерфейс, который упрощает использование подсистемы.
• Оберните сложную подсистему более простым интерфейсом.

Хотя вышеприведенное можно сказать, что оно применимо к вашему примеру, для меня это больше похоже на AbstractFactory . Возможно, вы захотите переименовать его в EntityFactory без части Doctrine, потому что тот факт, что он использует Doctrine внутри, является деталью реализации. Для общедоступного API Фабрики это не имеет значения. Возможно, вы захотите перейти с Doctrine на Propel позже, и тогда вам просто нужно изменить код внутри класса, но не API.

Вам также может быть интересен шаблон Gateway .

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