dci 0.1.0 → 0.2.0

data/.ruby

@@ -26,18 +26,18 @@ repositories:
   scm: git
   name: upstream
 resources:
-  home: https://rubyworks.github.com/dci
-  code: https://github.com/rubyworks/dci
+  home: http://rubyworks.github.com/dci
+  code: http://github.com/rubyworks/dci
   mail: http://groups.google.com/groups/rubyworks-mailinglist
 extra: {}
 load_path:
 - lib
 revision: 0
-version: 0.1.0
+version: 0.2.0
 name: dci
 title: DCI
 summary: DCI for Ruby
 created: '2011-03-04'
 description: Faithful DCI framework for Ruby application development.
 organization: Rubyworks
-date: '2012-02-07'
+date: '2012-02-08'

data/demo/account_example.md

@@ -28,14 +28,14 @@ a balance of $100. (We're generous like that.)
 We set up two Roles, one role for withdrawing money from an account,
 and one for depositing money into an account.
 
-    class Account::TransferWithdraw < Role
+    class Account::TransferWithdraw < DCI::Role
       def transfer(amount)
         decrease_balance(amount)
         #log "Tranfered $#{amount} from account ##{account_id}."
       end
     end
 
-    class Account::TransferDeposit < Role
+    class Account::TransferDeposit < DCI::Role
       def transfer(amount)
         increase_balance(amount)
         #log "Tranfered $#{amount} into account ##{account_id}."
@@ -46,7 +46,7 @@ Now we create a Context which will assign accounts to the roles
 and used to perfomr the transfer.
 
     # We can think of a context as setting a scene.
-    class Account::Transfer < Context
+    class Account::Transfer < DCI::Context
       role :source_account      => Account::TransferWithdraw
       role :destination_account => Account::TransferDeposit
 

data/lib/dci/context.rb

@@ -1,89 +1,105 @@
-# Context - The Context is the class (or its instance) whose code includes the roles
-# for a given algorithm, scenario, or use case, as well as the code to map these
-# roles into objects at run time and to enact the use case. Each role is bound
-# to exactly one object during any given use case enactment; however, a single
-# object may simultaneously play several roles. A context is instantiated at the
-# beginning of the enactment of an algorithm, scenario, or use case. In summary,
-# a Context comprises use cases and algorithms in which data objects are used
-# through specific Roles.
-#
-# Each context represents one or more use cases. A context object is instantiated
-# for each enactment of a use case for which it is responsible. Its main job
-# is to identify the objects that will participate in the use case and to
-# assign them to play the Roles which carry out the use case through their
-# responsibilities. A role may comprise methods, and each method is some small
-# part of the logic of an algorithm implementing a use case. Role methods run
-# in the context of an object that is selected by the context to play that role
-# for the current use case enactment. The role-to-object bindings that take place
-# in a context can be contrasted with the polymorphism of vernacular object-oriented
-# programming. The overall business functionality is the sum of complex, dynamic
-# networks of methods decentralized in multiple contexts and their roles.
-#
-# Each context is a scope that includes identifiers that correspond to its roles.
-# Any role executing within that context can refer to the other roles in that
-# context through these identifiers. These identifiers have come to be called
-# methodless roles. At use case enactment time, each and every one of these
-# identifiers becomes bound to an object playing the corresponding Role for
-# this Context.
-#
-# An example of a context could be a wire transfer between two accounts,
-# where data models (the banking accounts) are used through roles named
-# SourceAccount and # DestinationAccount. 
-#
-#     class Account::Transfer < Context
-#       role :source_account      => Account::TransferWithdraw
-#       role :destination_account => Account::TransferDeposit
-#
-#       def initialize(source_account, destination_account)
-#         self.source_account      = source_account
-#         self.destination_account = destination_account
-#       end
-#
-#       def transfer(amount)
-#         roles.each{ |role| role.transfer(amount) }
-#       end
-#     end
-#
-class Context
+module DCI
 
-  # Define a role given the name the role will use in this context,
-  # and the role class that is to be played.
+  # Context - The Context is the class (or its instance) whose code includes the roles
+  # for a given algorithm, scenario, or use case, as well as the code to map these
+  # roles into objects at run time and to enact the use case. Each role is bound
+  # to exactly one object during any given use case enactment; however, a single
+  # object may simultaneously play several roles. A context is instantiated at the
+  # beginning of the enactment of an algorithm, scenario, or use case. In summary,
+  # a Context comprises use cases and algorithms in which data objects are used
+  # through specific Roles.
   #
-  def self.role(name_to_role)
-    name_to_role.each do |name, role|
-      define_method("role_#{name}"){ role }
+  # Each context represents one or more use cases. A context object is instantiated
+  # for each enactment of a use case for which it is responsible. Its main job
+  # is to identify the objects that will participate in the use case and to
+  # assign them to play the Roles which carry out the use case through their
+  # responsibilities. A role may comprise methods, and each method is some small
+  # part of the logic of an algorithm implementing a use case. Role methods run
+  # in the context of an object that is selected by the context to play that role
+  # for the current use case enactment. The role-to-object bindings that take place
+  # in a context can be contrasted with the polymorphism of vernacular object-oriented
+  # programming. The overall business functionality is the sum of complex, dynamic
+  # networks of methods decentralized in multiple contexts and their roles.
+  #
+  # Each context is a scope that includes identifiers that correspond to its roles.
+  # Any role executing within that context can refer to the other roles in that
+  # context through these identifiers. These identifiers have come to be called
+  # methodless roles. At use case enactment time, each and every one of these
+  # identifiers becomes bound to an object playing the corresponding Role for
+  # this Context.
+  #
+  # An example of a context could be a wire transfer between two accounts,
+  # where data models (the banking accounts) are used through roles named
+  # SourceAccount and # DestinationAccount. 
+  #
+  #     class Account::Transfer < Context
+  #       role :source_account      => Account::TransferWithdraw
+  #       role :destination_account => Account::TransferDeposit
+  #
+  #       def initialize(source_account, destination_account)
+  #         self.source_account      = source_account
+  #         self.destination_account = destination_account
+  #       end
+  #
+  #       def transfer(amount)
+  #         roles.each{ |role| role.transfer(amount) }
+  #       end
+  #     end
+  #
+  class Context
 
-      module_eval %{
-        def #{name}=(data)
-          @#{name} = role_#{name}.new(data)
-        end
+    # Define a role given the name the role will use in this context,
+    # and the role class that is to be played.
+    #
+    def self.role(name_to_role)
+      @roles = nil  # reset
+
+      name_to_role.each do |name, role|
+        define_method("role_#{name}"){ role }
 
-        def #{name}
-          @#{name}
+        module_eval %{
+          def #{name}=(data)
+            @#{name} = role_#{name}.new(data)
+          end
+
+          def #{name}
+            @#{name}
+          end
+        }
+      end
+    end
+
+    # Return a list of the names of defined roles.
+    #
+    # TODO: Consider private vs public roles.
+    def self.roles
+      @roles ||= (
+        list = []
+        instance_methods.each do |name|
+          next unless name.to_s.start_with?('role_')
+          list << name.to_s[5..-1].to_sym
         end
-      }
+        list    
+      )
     end
-  end
 
-  # The default contructor can be used to assign roles via
-  # a settings hash.
-  #
-  def initialize(settings={})
-    settings.each do |k,v|
-      __send__("#{k}=", v)
+    # The default contructor can be used to assign roles via
+    # a settings hash.
+    #
+    def initialize(settings={})
+      settings.each do |k,v|
+        __send__("#{k}=", v)
+      end
     end
-  end
 
-  # Returns a list of all roles in the context.
-  #
-  # @todo Return value should probably be cached.
-  def roles
-    list = []
-    methods.each do |name|
-      next unless name.to_s.start_with?('role_')
-      list << __send__(name.to_s.sub('role_',''))
+    # Return Array of all role instances in the context.
+    #
+    def roles
+      self.class.roles.map do |name|
+        __send__(name)
+      end
     end
-    list
+
   end
 
 end

data/lib/dci/role.rb

@@ -1,53 +1,56 @@
-# Interaction - The Interaction is "what the system does." The Interaction
-# is implemented as Roles which are played by objects at run time. These objects
-# combine the state and methods of a Data (domain) object with methods (but no
-# state, as Roles are stateless) from one or more Roles. In good DCI style,
-# a Role addresses another object only in terms of its (methodless) Role. There
-# is a special Role called `@self` which binds to the object playing the current
-# Role. Code within a Role method may invoke a method on `@self` and thereby
-# invoke a method of the Data part of the current object. One curious aspect
-# of DCI is that these bindings are guaranteed to be in place only at run time
-# (using a variety of approaches and conventions; C++ templates can be used to
-# guarantee that the bindings will succeed). This means that Interactions—the
-# Role methods—are generic. In fact, some DCI implementations use generics or
-# templates for Roles.
-#
-# A Role is a stateless programming construct that corresponds to the end user's
-# mental model of some entity in the system. A Role represents a collection of 
-# responsibilities. Whereas vernacular object-oriented programming speaks of
-# objects or classes as the loci of responsibilities, DCI ascribes them to Roles.
-# An object participating in a use case has responsibilities: those that it takes
-# on as a result of playing a particular Role.
-#
-# In the money transfer use case, for example, the role methods in the
-# SourceAccount and DestinationAccount enact the actual transfer.
-#
-#     class Account::TransferWithdraw < Role
-#       def transfer(amount)
-#         decrease_balance(amount)
-#         log "Tranfered from account #{account_id} $#{amount}"
-#       end
-#     end
-#
-#     class Account::TransferDepoit < Role
-#       def transfer(amount)
-#         increase_balance(amount)
-#         log "Tranfered into account #{account_id} $#{amount}"
-#       end
-#     end
-#
-class Role
+module DCI
 
+  # Interaction - The Interaction is "what the system does." The Interaction
+  # is implemented as Roles which are played by objects at run time. These objects
+  # combine the state and methods of a Data (domain) object with methods (but no
+  # state, as Roles are stateless) from one or more Roles. In good DCI style,
+  # a Role addresses another object only in terms of its (methodless) Role. There
+  # is a special Role called `@self` which binds to the object playing the current
+  # Role. Code within a Role method may invoke a method on `@self` and thereby
+  # invoke a method of the Data part of the current object. One curious aspect
+  # of DCI is that these bindings are guaranteed to be in place only at run time
+  # (using a variety of approaches and conventions; C++ templates can be used to
+  # guarantee that the bindings will succeed). This means that Interactions—the
+  # Role methods—are generic. In fact, some DCI implementations use generics or
+  # templates for Roles.
   #
-  def initialize(player)
-    @self = player
-  end
-
+  # A Role is a stateless programming construct that corresponds to the end user's
+  # mental model of some entity in the system. A Role represents a collection of 
+  # responsibilities. Whereas vernacular object-oriented programming speaks of
+  # objects or classes as the loci of responsibilities, DCI ascribes them to Roles.
+  # An object participating in a use case has responsibilities: those that it takes
+  # on as a result of playing a particular Role.
+  #
+  # In the money transfer use case, for example, the role methods in the
+  # SourceAccount and DestinationAccount enact the actual transfer.
+  #
+  #     class Account::TransferWithdraw < Role
+  #       def transfer(amount)
+  #         decrease_balance(amount)
+  #         log "Tranfered from account #{account_id} $#{amount}"
+  #       end
+  #     end
+  #
+  #     class Account::TransferDepoit < Role
+  #       def transfer(amount)
+  #         increase_balance(amount)
+  #         log "Tranfered into account #{account_id} $#{amount}"
+  #       end
+  #     end
   #
-  # @todo Should use #public_send?
-  def method_missing(s, *a, &b)
-    @self.__send__(s, *a, &b)
+  class Role
+
+    #
+    def initialize(player)
+      @self = player
+    end
+
+    #
+    # @todo Should use #public_send?
+    def method_missing(s, *a, &b)
+      @self.__send__(s, *a, &b)
+    end
+
   end
 
 end
-

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: dci
 version: !ruby/object:Gem::Version
-  version: 0.1.0
+  version: 0.2.0
   prerelease: 
 platform: ruby
 authors:
@@ -9,11 +9,11 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2012-02-07 00:00:00.000000000 Z
+date: 2012-02-09 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: detroit
-  requirement: &12149120 !ruby/object:Gem::Requirement
+  requirement: &12937320 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -21,10 +21,10 @@ dependencies:
         version: '0'
   type: :development
   prerelease: false
-  version_requirements: *12149120
+  version_requirements: *12937320
 - !ruby/object:Gem::Dependency
   name: qed
-  requirement: &12148360 !ruby/object:Gem::Requirement
+  requirement: &12935480 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -32,7 +32,7 @@ dependencies:
         version: '0'
   type: :development
   prerelease: false
-  version_requirements: *12148360
+  version_requirements: *12935480
 description: Faithful DCI framework for Ruby application development.
 email:
 - transfire@gmail.com
@@ -54,7 +54,7 @@ files:
 - COPYING.md
 - HISTORY.md
 - README.md
-homepage: https://rubyworks.github.com/dci
+homepage: http://rubyworks.github.com/dci
 licenses:
 - BSD-2-Clause
 post_install_message: