DCI and ruby

M

Michel Demazure

The following post is interesting

http://andrzejonsoftware.blogspot.com/2011/02/dci-and-rails.html

In the DCI way, an object can be assigned a role by extending a module
bringing the methods pertaining to this role

obj = Klass.new
obj extend Role

But, how to change roles, without cluttering the metaclass hierarchy ?

obj unextend Role # ?
obj extend NewRole

But, even with an ah-hoc unextend, one needs to remember the old role.
Therefore, what about a 'temp_extend Module' method, which clears the
previous 'temp_extension' ?

_md
 
J

Jason Stewart

The following post is interesting

http://andrzejonsoftware.blogspot.com/2011/02/dci-and-rails.html

In the DCI way, an object can be assigned a role by extending a module
bringing the methods pertaining to this role

obj = Klass.new
obj extend Role

But, how to change roles, without cluttering the metaclass hierarchy ?

I read the article and found it interesting as well. How about
mixology? (http://rubyforge.org/projects/mixology/) It lets you mix in
and unmix to get the old behavior back.

Cheers,
Jason
 
R

Ryan Davis

The following post is interesting
=20
http://andrzejonsoftware.blogspot.com/2011/02/dci-and-rails.html
=20
In the DCI way, an object can be assigned a role by extending a module
bringing the methods pertaining to this role
=20
obj =3D Klass.new
obj extend Role
=20
But, how to change roles, without cluttering the metaclass hierarchy ?
=20
obj unextend Role # ?

I wrote the 'un' gem which has uninclude and unextend. Passes tests on =
1.8 and 1.9.

Tho I've got to say that I'm not sure what DCI does that decorations =
don't. Seems this can all be done via composition and delegation quite =
easily. *shrug*
 
A

Andrzej K.

Ryan Davis wrote in post #981451:
Tho I've got to say that I'm not sure what DCI does that decorations
don't. Seems this can all be done via composition and delegation quite
easily. *shrug*

DCI and composition can work together very nicely in my opinion. In this
context DCI just gives you a way of not declaring all of the delegations
in one class, but split it and use and role at a time.

Assuming that in Redmine codebase it's the User class that is
responsible for most of the UI actions. In that case User would contain
lots of associations:

has_many :issues, :eek:wned_issues, :projects, :comments, :attachments

It would probably delegate some of the logic to classes like
ProjectManager, IssueOwner, IssueReporter etc.

It's all mixed together at the class level.

With DCI you would still have the "composition" classes/modules, but now
they will be injected runtime, so no need to have them in one place in
the User class.

I'm not sure if it's good or bad. I like this way of thinking that now
I'm talking to "this" role of the user object, so I don't care about
other roles. I also like the fact that the base User class is now much
smaller.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top