Подход данных по отношению к Push OOP

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

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

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

Ответ 1

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

Связанная статья о злых геттерах

Ответ 2

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

Из здесь обсуждается вопрос о том, должна ли модель наблюдателя быть основана на push или pull:

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Вот белый документ, написанный IBM по этой теме. http://www.ibm.com/developerworks/library/specification/ws-pubsub/

Ответ 5

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

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

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

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

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

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

Ответ 6

назначения. Нажмите (источник)

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

источник. Извлечь (назначения)

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

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

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

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

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

Ответ 7

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

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

В монолитном настольном приложении это может быть совершенно иначе. Вероятно, вы используете варианты "Model-View-Controller" и шаблоны наблюдателей и т.д. В этом случае вы указываете информацию, например. к пользовательскому интерфейсу.

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

@kamil-tomsik. Как вы думаете, на модели клиентского сервера, где у вас сотни клиентов, которые являются наблюдателями, но им не нужны одинаковые данные, поэтому, если вы нажмете, вы должны отправить им все нужные данные чтобы поделиться, но некоторые из них им не нужны. Разве это не замедляет общение?

Ответ 12

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