Взаимодействие контекста данных: эволюция объектно-ориентированной парадигмы

Пример кода

Это привет мир пример для DCI. Все заинтересованные в DCI начинают с перевода денег с одного счета на другой.

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

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

	class Account
	def decrease_balance(amount); end
	def increase_balance(amount); end
	def balance; end
	def update_log(message, amount); end
	def self.find(id); end
	end

view raw
account.rb
hosted with by GitHub

Как видите, все методы здесь локальны и не зависят от контекста. Аккаунт ничего не знает о переводе денег. Он отвечает только за увеличение и уменьшение своего баланса. Логика перевода денег в контексте:

	class TransferringMoney
	include Context
	def self.transfer source_account_id, destination_account_id, amount
	source = Account.find(source_account_id)
	destination = Account.find(destination_account_id)
	TransferringMoney.new(source, destination).transfer amount
	end
	attr_reader :source_account, :destination_account
	def initialize source_account, destination_account
	@source_account = source_account.extend SourceAccount
	@destination_account = destination_account.extend DestinationAccount
	end
	def transfer amount
	in_context do
	source_account.transfer_out amount
	end
	end
	…
	end

view raw
context.rb
hosted with by GitHub

Я извлекаю две учетные записи из базы данных, затем создаю экземпляр контекста и затем вызываю «перевод». Возможно, вы заметили, что я передаю эти два счета конструктору, а сумму — методу transfer . Делая это, я пытаюсь понять, какие объекты являются действующими лицами в этом взаимодействии, а какие — просто данными. Счета — актеры, у них есть поведение. Количество данных.

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

Наконец, я запускаю это взаимодействие, вызывая «Transfer_out» на исходном аккаунте. В этом примере контекст только запускает взаимодействие, но в некоторых сложных случаях он также может координировать актеров.

Теперь давайте посмотрим, как реализованы роли:

	class TransferringMoney
	include Context
	…
	def transfer amount
	…
	end
	module SourceAccount
	include ContextAccssor
	def transfer_out amount
	raise «Insufficient funds» if balance < amount
	decrease_balance amount
	context.destination_account.transfer_in amount
	update_log «Transferred out», amount
	end
	end
	module DestinationAccount
	include ContextAccssor
	def transfer_in amount
	increase_balance amount
	update_log «Transferred in», amount
	end
	end
	end

view raw
roles.rb
hosted with by GitHub

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

Здесь есть несколько интересных вещей:
* Разделение между стабильным поведением и контекстным поведением. Account — это класс дампа, который знает только, как манипулировать данными. Все проверки, вся бизнес-логика в контексте.
* Роли получают доступ к другим соавторам через переменную контекста. Еще раз, это сделано, чтобы отделить актеров от данных. Если я передам все как аргумент, как я узнаю, что такое актер, а что нет? Следовательно, все акторы доступны через контекст, а все объекты данных передаются в качестве аргументов.

Контекст и обе роли:

	class TransferringMoney
	include Context
	def self.transfer source_account_id, destination_account_id, amount
	source = Account.find(source_account_id)
	destination = Account.find(destination_account_id)
	TransferringMoney.new(source, destination).transfer amount
	end
	attr_reader :source_account, :destination_account
	def initialize source_account, destination_account
	@source_account = source_account.extend SourceAccount
	@destination_account = destination_account.extend DestinationAccount
	end
	def transfer amount
	in_context do
	source_account.transfer_out amount
	end
	end
	module SourceAccount
	include ContextAccssor
	def transfer_out amount
	raise «Insufficient funds» if balance < amount
	decrease_balance amount
	context.destination_account.transfer_in amount
	update_log «Transferred out», amount
	end
	end
	module DestinationAccount
	include ContextAccssor
	def transfer_in amount
	increase_balance amount
	update_log «Transferred in», amount
	end
	end
	end

view raw
context_and_roles.rb
hosted with by GitHub

Что мы получили

Местонахождение

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

фокус

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

«Что такое система» и «Что делает система»

«Что такое система» — это все объекты данных и их локальные методы. Обычно эта часть системы очень стабильна. «Что делает система» — это контекстуальное поведение, которое быстро меняется. Отделение стабильных частей от быстро меняющихся очень важно для создания стабильного программного обеспечения. И DCI обеспечивает это разделение:
* Класс DCI говорит все о внутренней части объекта и ничего о его соседях («Что такое система»).
* Контекст DCI говорит все о сети взаимодействующих объектов и ничего об их внутренностях («Что делает система»).

Исходный код == Runtime

Другое дело, что исходный код соответствует среде выполнения. Среда выполнения сообщает нам, что есть два аккаунта и сумма. Это то, что вы видите, когда открываете контекст.

Роли явные

Самое большое, что приносит DCI — это явные роли. Многие дизайнеры сходятся во мнении, что объекты сами по себе не имеют обязанностей — роли есть. Например, возьмите меня в качестве примера объекта. У меня есть следующие свойства: я родился на русском языке; меня зовут Виктор; мой вес около 65 кг. Эти свойства действительно подразумевают некоторые обязанности высокого уровня? Они не Но когда я прихожу домой и начинаю играть роль мужа, я становлюсь ответственным за все вещи этого мужа. Так что объекты играют роли. Тот факт, что роли не являются первоклассными гражданами в традиционной объектной ориентации, просто ошибочен.

Ресурсы

Если вы считаете эту идею интересной, вам следует проверить следующие ресурсы:

• http://dci-in-ruby.info
• http://fulloo.info

Если вы предпочитаете читать книги, я могу порекомендовать вам три книги:

• Чистый Рубин Джимом Гаем. Эта книга заполняет потребность в практическом введении в DCI для Rubyists. Это все еще в стадии разработки, но выглядит очень многообещающе.
• Lean Architecture: для гибкой разработки программного обеспечения Джеймсом О. Коплиеном и Гертрудой Бьёрнвиг.
  «Это не только первая на рынке книга по Lean Architecture и гибкой разработке, но она разъясняет разницу между этими двумя мощными подходами и показывает, как их можно комбинировать. Это также первая книга, в которой представлена ​​новая программная архитектура Trygve Reenskaug под названием DCI: данные, контекст и взаимодействие. DCI для программиста так же, как классическая архитектура MVC для конечного пользователя: программный подход, который ставит людей на первое место ».
• Проектирование объектов: роли, обязанности и совместная работа Ребекки Вирфс-Брок и Алана Маккина. Поскольку эта книга была опубликована в 2002 году, она не охватывает DCI. Но это отличный материал по проектированию объектов, использованию ролей и совместной работе по моделированию. Эти темы тесно связаны с основными идеями DCI.