Good and clear introduction to DCI with Ruby.

I didn't try to extend roles on the fly yet. But I separate Object from Role using Concerns:

class BankAccount
  include FundingSource
  include Verifiable
  # [...]
end

I really like what you are doing with these articles, keep going!.

Hi Jim

Today is the first time I heard of DCI. What I don't get is the real difference between DCI and correct OOP (for example in the DDD sense). What are roles other then Objects of a specific class with methods that do the work by wrapping the Entity Object in a specific purpose API. It looks like an (maybe extended) application of the facade pattern.

The roles have to have knowledge about the Entities (or Data Objects in your parlance) to do something with the encapsulated data. So effectively they are coupled and reuse is limited to data objects providing those API-Parts that are needed.

Maybe you can enlighten me.

Regards
Dirk

@Phillipe, that's a good idea. It helps order your code, but in the end your object still knows more than it has to for most of the time.

By always including those concerns, they infect code and tests for unrelated functions. And the you need to understand a lot more about that class in every place you use it.

I'd love to hear what you think when you try it.

@Luis thanks! I will.

@Dirk
This pattern is similar to facades, presenters or decorators but an important part of this approach is that these roles are not objects. With DCI you use the object of concern and thereby avoid self-schizophrenia (the topic of my next article).

I don't see the importance of this distinction (yet).

In my understanding (I have literally no practice in AOP) concerns aka aspects ARE objects (in most programming languages) whose identity is irrelevant, which don't have any state and can't reasonably treated standalone. Only the defined methods (the behavior) regarding the "wrapped" entity are of any importance. What makes them different? Why not use "normal" Objects for that purpose?

I'm looking forward to your next article.

Regards
Dirk

Interesting approach but it doesn't look really practical. Do you have a real project that you can share that uses that approach ? My impression is that you are going to have the following issues:

Object role exclusion and lifetime: Because it's not possible to uninclude a module 1, you have to make sure to collect the object if the role is not applicable anymore. Example: user is no longer an admin but was already extended with the AdminRole methods. It's not an issue in a rails controller because the lifetime of an object is bound to the life of the request. I don't know a better workaround that having all admin methods check for is_admin?.

Object and methods no longer have a clear relationship: Because methods are added on the fly, you take the risk of having some of the user object that don't respond_to? :completed_application?. Clearly in the example it's not an issue but if the user object is passed from multiple sources to a method it might be the case. I can see how you might ending up always extending an object in some part of your code just to make sure that it behaves correctly. Did you see these kind of issues ?

Method name collision as with sub-classing: You have to make sure that modules that are going to be used on the same object don't provide the same methods. If it happens, it's even worse than when sub-classing; depending on the module inclusion order, you will get different behavior. It's possible to avoid that with conventions like prefixing your methods with the role name.

In general, I think that these issues can be solved nicely with object composition. Here is my take of it:

class UserApplication
  attr_reader :user
  def initialize(user); @user = user end
  def completed_application?; ... ; end
  def prepare_for_acceptance; ... ; end
end

class User
  def application; UserApplication.new(self); end
end

When you have that application object you are sure what methods it hold and how they work. You can also generalize it by checking the object passed in the UserApplication initializer with duck-typing with the methods that you will need in #completed_application? and #prepare_for_acceptance. If you want some of the user methods on your UserApplication instance, you can also use the stdlib forwardable module which I also find under-utilized:

require 'forwardable'
class UserApplication
   extend Forwardable
   def_delegators :@user, :name, :email, :admin?
end

Cheers, zimbatm

Jim,

I'm not sure if we've formally met; I believe we know a lot of the same folks. I'm just starting to read and learn about DCI (thanks to your articles). Plus, I'm looking for a November speaker for my Ruby Users Group: http://cvreg.org.

If you have the bandwidth and the enthusiasm, I think a few folks would appreciate a DCI primer. Feel free to contact me directly: mriffe [at] gmail.

Cheers, Mel

Thanks, everyone, for your comments. I'm traveling for ArrrrCamp and need to catch up with my responses. Bear with me. I'll reply here after the conference (or during if I can steal away some time) and will be writing more about aspects of DCI in the future.

Great article! thanks

Maybe if Ruby's mixin system supported efficient unmixing, this would be workable, but as is I think zimbatm is about right. However I can envision makeing it easier with an API, something like.

@zimbatm there is a downside to this approach both in the mental model of the code as well as the appearance of self-schizophrenia, but I'll be writing about that aspect next.

@trans there are some gems that allow you to unmix functionality by tapping into the underlying C code. And I have a working example of code using almost the exact same method you mention: "as"

The gem 'mixology' provides an `unextend` method that removes a module from the singleton class' ancestor chain, but it is not pure Ruby: it is implementation-specific and MRI & JRuby are currently supported. Perhaps there are other, similar approaches of which I am not aware.

My point being, I personally find it rather questionable to attempt building something like DCI on such a niche foundation.

To be fair, I have never experienced the 'self-schizophrenia' issues alluded to in the DCI literature, but I have also never seen an example of this phenomenon furnished. I remain convinced that composition is a perfectly suitable approach for the Role/Data relationship.

If need be, a Role's identity test can be forwarded to the role-player (Data), just like every other method. In the absence of a concrete example, I'm left to conclude that the fear of self-schizophrenia is a red herring, or perhaps a concern born in other languages where object identity tests are not overridable methods.

What, after all, does `extend`/`unextend` give you that `class DCI::Role < SimpleDelegator` lacks?

A splendid introduction to DCI. But rather single-sided. Yes, roles (interaction part) are very important in DCI, but context is as important. Context gives you a way to represent a use case of application in a nice procedural way. Instead of classical OOP way: we have bunch of objects, and now they begin to send messages and somehow interact, and it is impossible to infer a use case by reading classes code. In classical OOP all object interactions are in runtime (in your code there are only classes). But with Context and roles code is much more closer to runtime object configuration.

Also I thing you did not mention clear enough an idea of separation of Data and Interaction. Data is made up of basic Domain objects. All their methods and data structures are specific only to Domain. They know nothing about application specific use cases, but they try to grasp the essence of Domain model (like in DDD), its main concepts, association, maybe some basic domain logic. Ideally, you should be able to pack your Data objects as a gem and reuse them in applications of the same Domain again and again (although i don think that it really should be done, it is more like a metric whether your data object are separated enough from Interactions).

@ Gomez

You don need to unextend your objects in DCI.
Objects are created and live only for duration of one Context.

If you wanted roles to be less "sticky" you could use a proxy instead of a mixin:

tom = Person.new(:fname => 'Tommy', :mname => 'Lee', :lname => 'Jones')
tom.greet # => "Hi, I'm Tommy"
tom = Actor.new(tom)
tom.greet # => "Hi, I'm Tommy Lee Jones" (overridden)
tom.pretend # (Actor verb)
tom.walk # (Person verb, accessed via message forwarding)

A factory method might even tell you what roles are registered:

tom.roles #=> [:actor, :chef]
tom.as(:actor) # => same as Actor.new(tom)

I've spent the last couple of weeks wrapping my head around the DCI architecture, and most of it makes sense. The one bit that I haven't really figured out and that's how persistence works in a DCI architecture.

My initial thought would be to represent the User model as a plain old object. Then when I want to save an instance to a data store, I might have a SaveUserContext and a Persist role.

I am just curious how other's are handling persistence in a DCI architecture.

Though it makes sense to me that we should split what our system is and what our system does, but impact on the performance by introducing this programming practice is huge, here's a snippet showing the performance impact, https://gist.github.com/1459333

Just remembered what we had been discussing earlier. I found the missing background information.

Long story short, an extending module ("extender") can have a self.included method that will get called when the module gets included in something else ("base"). This method gets an arg that represents the base. So, it can use respond_to? on that, to see whether it supports various messages, has various attributes, etc. This can be used to enforce DBC (Design By Contract).

Also, since we're talking about stuff being changed dynamically, another idea pops to mind. The extender could just stash the identity of the base, and check later. That could eliminate dependencies on the order in which various extensions are added.

Good post!I have read all the statement of this blog.I know that there are a little difference in the class oriented and object oriented programming. classes and inheritance to define object behavior is that the behavior is fixed at compile time and your objects are limited in what actions they perform.

Thanking you.

Enjoying your disscusion on DCI. I'm interested in your Clean Ruby book, but was wondering if there were a sample chapter to look over. At least for me, 40-50 dollars is a fairly steep commitment.

Thanks