ltello / dci-ruby

Data Context Interaction, the evolution of OO, available in Ruby

dci-ruby¶ ↑

Trygve Reenskaug, the parent of MVC, proposes an evolution to traditional OO paradigm. (www.artima.com/articles/dci_vision.html). This gem makes Data-Context-Interaction paradigm ready to be used in your Ruby application. See also (rubysource.com/dci-the-evolution-of-the-object-oriented-paradigm/).

Installation¶ ↑

Install as usual, either with rubygems

gem install dci-ruby

or including it in your Gemfile and running bundle install:

# Gemfile
gem "dci-ruby"

Use¶ ↑

dci-ruby gives you the class DCI::Context to inherit from to create your own contexts:

class MoneyTransfer < DCI::Context

  # Roles

  role :source_account do
    def transfer(amount)
      player.balance -= amount
    end
  end

  role :target_account do
    def get_transfer(amount)
      player.balance += amount
    end
  end

  # Interactions

  def run(amount = settings(:amount))
    source_account.transfer(amount)
    target_account.get_transfer(amount)
  end
end

Every context defines some roles to be played by external objects (players) and their interactions. This way you have all the agents and operations in a use case wrapped in just one entity instead of spread out throughout the application code.

Use the defined contexts, instantiating them, wherever you need in your code:

MoneyTransfer.new(:source_account => Account.new(1),
                  :target_account => Account.new(2)).run(100)

or the short preferred way:

MoneyTransfer[:source_account => Account.new(1),
              :target_account => Account.new(2),
              :amount         => 100]

In a context instance, every role instantiates an object (roleplayer) that gathers the behaviour defined inside its role, and has private access to the original object adopting the role (player): the Account instances above are players.

The instance of MoneyTransfer::SourceAccount and the one of MoneyTransfer::TargetAccount are roleplayers. They are accesible inside #run through #source_account and #target_account private methods. Also, every roleplayer has private access to the rest of roleplayers in the context.

Unlike extending players with role modules this Presenter approach gets on well with ruby method call caching mechanism. (see Tony Arcieri’s article DCI in Ruby is completely broken)

When instanciating a Context, the extra no-role pairs given as arguments are read-only attributes accessible via #settings:

MoneyTransfer[:source_account => Account.new(1),
              :target_account => Account.new(2),
              :amount => 500]

here, :amount is not a player (has no associated role) but is still privately accessible both in the interactions and the roles via #settings(:amount).

Inside a role definition, use the macro

delegate_to_player :player_methodname, :role_method_name

to create a method delegating its behaviour to the object playing the role (player) so a roleplayer can also respond to a player’s method.

delegates_to_player :methodname1, :methodname2... (for multiple methods delegation in just one sentence)

There are also private counterpart macros (private_delegate_to_player and private_delegates_to_player) to create private delegations not accessible outside a roleplayer.

See the examples folder for examples of use and the DCI-Sample repository for a sample Rails application using DCI through this gem.

Notice how your models and controllers are not overloaded anymore. They are thinner and simpler. Also note how now most of the functionality of the system is isolated, totally dry-ied and easily maintainable in the different context classes.

Copyright¶ ↑

Copyright © 2012, 2013 Lorenzo Tello. See LICENSE.txt for further details.