5 ms·

I'm "thinking in DCI" for 2 years now. At GameBoxed (http://gameboxed.com/ http://gameboxed.com/) we've got a Rails app that uses a lot of .extend on every req

I'm "thinking in DCI" for 2 years now. At GameBoxed (http://gameboxed.com/ http://gameboxed.com/) we've got a Rails app that uses a lot of .extend on every request. It's in production for 1.5 year now. It's a backend for multiple social games (one backend app for many CoffeeScript frontends). It's not huge in terms of traffic and performance needs. We implemented it with a DCI-like architecture in mind. It was helpful at the beginning. DCI wasn't the only way to implement it, but it was the simplest way for us at that time. We've had some performance problems, but they were never related to the usage of .extend. If it was a performance problem, we would probably consider removing the .extends (not a big deal), switch to Java, do more caching, there are so many options. Again, we don't have huge performance needs, we've maybe 40 req/s at peak times. DCI is much more than .extend, it's a huge shift in thinking about the OOP architecture. If we (as Ruby community) agree that it's an architecture worth trying, then maybe it makes sense to introduce better optimisations techniques to the current Ruby implementations? Anyway, it's great to see the discussion happening. DCI may not be ready to use right now, but it's more of a change in thinking than in the implementation. I definitely wouldn't call it completely broken in Ruby. Here are some of my posts on DCI in Ruby: http://andrzejonsoftware.blogspot.com/2011/02/dci-and-rails.html http://andrzejonsoftware.blogspot.com/2011/02/dci-and-rails.... http://andrzejonsoftware.blogspot.com/2012/01/dci-and-rails-lessons-learnt.html http://andrzejonsoftware.blogspot.com/2012/01/dci-and-rails-... http://andrzejonsoftware.blogspot.com/2011/08/dci-patterns-how-to-write-dci-contexts.html http://andrzejonsoftware.blogspot.com/2011/08/dci-patterns-h...

bascule 14y ago
What does extend give you that delegation doesn't?
- andrzejkrzywda 14y ago
  At a code level - no need to write the delegation methods/macros. At the design level - flat hierarchy At an abstract level - thinking in terms of objects, not classes.
  - bascule 14y ago
    > At a code level - no need to write the delegation methods/macros. You don't have to. They're built into SimpleDelegator. Syntactically the difference is you'd write: class MyThing < SimpleDelegator instead of: module MyThing And do: MyThing.new(obj) instead of: obj.extend(myThing) > At an abstract level - thinking in terms of objects, not classes. It seems to me like you're trying to use a module to solve a problem which can be solved with an object. I don't think that's thinking in objects at all... it's thinking in modules.
    - andyl 14y ago
      With DCI do you ever need to extend/include multiple modules? Would this single-inheritance approach work?
      - halostatue 14y ago
        As long as the interactions you're working with don't implement the same methods, it would be trivially easy: class Account; …; end class Withdrawer < SimpleDelegator; …; end class Depositor < SimpleDelegator; …; end acc = Depositor.new(Withdrawer.new(Account.new)) acc.withdraw(40) acc.deposit(100) At least that's how I understand it. I'm not convinced that DCI is worth it, but…I don't yet have a need for it in the application that I'm working with.

bascule 14y ago

What does extend give you that delegation doesn't?

andrzejkrzywda 14y ago
At a code level - no need to write the delegation methods/macros. At the design level - flat hierarchy At an abstract level - thinking in terms of objects, not classes.
- bascule 14y ago
  > At a code level - no need to write the delegation methods/macros. You don't have to. They're built into SimpleDelegator. Syntactically the difference is you'd write: class MyThing < SimpleDelegator instead of: module MyThing And do: MyThing.new(obj) instead of: obj.extend(myThing) > At an abstract level - thinking in terms of objects, not classes. It seems to me like you're trying to use a module to solve a problem which can be solved with an object. I don't think that's thinking in objects at all... it's thinking in modules.
  - andyl 14y ago
    With DCI do you ever need to extend/include multiple modules? Would this single-inheritance approach work?
    - halostatue 14y ago
      As long as the interactions you're working with don't implement the same methods, it would be trivially easy: class Account; …; end class Withdrawer < SimpleDelegator; …; end class Depositor < SimpleDelegator; …; end acc = Depositor.new(Withdrawer.new(Account.new)) acc.withdraw(40) acc.deposit(100) At least that's how I understand it. I'm not convinced that DCI is worth it, but…I don't yet have a need for it in the application that I'm working with.