it-swarm.com.ru

Извлечение данных против Push OOP Подход

Когда я проектирую свою систему с нуля, я часто сталкиваюсь с дилеммой, должен ли мой объект Push передавать информацию в другие объекты OR, должны ли объекты извлекать необходимые данные из других объектов.

Есть ли что-то похожее на стандарт в дизайне OOP, что я бы предпочел извлечение данных объектами, а не извлечение данных в объекты? 

Может кто-нибудь опытный посоветовать, является ли один подход лучше другого с точки зрения долгосрочной перспективы, или когда структура/каркас/диаграмма OOP становится более сложной?

38
Bunkai.Satori

Согласно скажи, не спрашивай , Push лучше - или больше ОО. Вы не хотите запрашивать данные у объекта, чтобы вы могли что-то сделать, вы хотите, чтобы это делал объект, потому что он тот, кто знает его данные.

Статьи по теме о злых добытчиков

23
Kamil Tomšík

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

Из здесь обсуждаем, должна ли модель наблюдателя быть на основе Push или Pull:

Кто запускает обновление?

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

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

20
mydogisbox

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

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

Тяга : Единственное преимущество, которое я вижу в тянущем подходе - это то, что компонент, который тянет, точно знает, когда он должен тянуть. Он может инициировать диалог, когда ему нужны данные, и ни один компонент не знает (или не должен знать), когда нужны данные, чем компонент, которому они нужны.

Мой вывод по этому вопросу: какой бы компонент ни принадлежал транзакции, он инициирует транзакцию . Если вы извлекаете данные из API, очевидно, что клиент API будет владеть транзакцией, поэтому сделаем попытку. Если вы передаете сообщение, то вещатель владеет транзакцией, поэтому он выполняет Push. 

18
ralzaul

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

Причина, по которой я говорю это из-за последних тенденций в дизайне. Domain Driven Design и CQRS будучи одними из самых выдающихся, они способствуют слабой связи, что очень хорошо.

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

Это делает объект независимым от других объектов и делает его более переносимым (не нужно менять, куда он толкает, так как он будет извлечен).

TL; DR Я бы порекомендовал тянуть над толканием.

ПРИМЕЧАНИЕ: все эти различные шаблоны проектирования не исключают друг друга, но сосуществуют.

3
Tehnix

назначение . Push (источник)

  • Назначение знает, что и как получить данные из источника
  • Назначение должно зависеть от источника, или
  • иначе Source должен реализовать предоставленный интерфейс ISource и зависеть от провайдера (может быть пакет Destination)
  • Метод имеет прямой частный доступ к Destination.

источник . тянуть (пункт назначения)

  • Источник знает что и как поставить в пункт назначения
  • Источник должен зависеть от пункта назначения, или
  • иначе Назначение должно реализовывать предоставленный интерфейс IDestination и зависеть от провайдера (может быть пакет Source)
  • Метод имеет прямой частный доступ к источнику.

Выберите ваше решение, посмотрев на зависимости, которые вы хотите иметь в своем коде.

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

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

Если один внешний метод не может выполнить действие на каком-либо ISource и любом IDestination, тогда вы можете захотеть взглянуть на шаблон Visitor, класс Visitor, выполняющий все конкретные действия для конкретных Source1 и SourceX Destination1 и DestinationY.

2
franckspike

Слово Push/Pull является относительным. Там будет толкач, у которого есть данные, и там будет пуллер, которому нужны данные. Если мы на самом деле храним данные в нейтральном месте, а не внутри Push-er/pull-er, появляется много возможностей, подходящих для данной проблемы в одно время. Один обновляет данные, когда он у них есть (отправляет уведомление при необходимости), а другие извлекают данные. данные по его усмотрению .. Многие шаблоны проектирования, MVC, Observer, Command и т. д. находятся на своем месте для обработки сценария.

1
Senthil

Ответ зависит от ваших архитектурных целей, другими словами, нет общего решения.

В архитектуре клиент-сервер у вас, вероятно, будет многоуровневая система на бэкэнде, в которой объекты извлекают состояние из других объектов. Это означает, что только определенные «службы» в конечном итоге обновят состояние объекта. Пример: создание нового объекта, обновление поля объекта и т.д. (Например, добавление нового элемента заказа к общему заказу).

В настольном монолитном приложении это может быть совершенно иначе. Скорее всего, вы используете вариации «Модель-Вид-Контроллер», шаблоны наблюдателей и т.д. В этом случае вы нажимаете «Информация», например, в интерфейс.

1
Angel O'Sphere

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

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

Создайте метод длинного опроса, который извлекает данные из полуоткрытой конечной точки Push-URL (также называемой веб-сервисом для pubsub), а затем обновляет все, что необходимо обновить, с помощью шаблона проектирования издатель-подписчик в вашем клиенте. Таким образом, ваши обновления более отделены от источника данных.

Вот статья, написанная IBM на эту тему. http://www.ibm.com/developerworks/library/specification/ws-pubsub/

1
Kristian

Во-первых, общая рекомендация такова: объектами являются data и поведения. Это поощряет меньшее количество получателей и тем меньше вытягивает, предоставляя методы, которые делают что-то с внутренними данными.

Само по себе «Push is лучше» (в принятом ответе) не может работать, так как Push-операция в некотором классе может потребовать нового нажатия на объект push. Вместо этого рекомендуется добавлять операцию Push, где она лучше всего подходит для абстракции. Это может даже привести к появлению нового, более абстрактного класса/композиции классов (см. Объектно-ориентированная эвристика проектирования , Riel, 1996, с. 37 и далее).

1
sevenforce

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

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

0
Grady Player