10 ms·

Clean Ruby is all about writing applications that are easy to understand by elevating the use case to a first class citizen. OO programs often split out method

Clean Ruby is all about writing applications that are easy to understand by elevating the use case to a first class citizen. OO programs often split out methods and objects required for a use case like shrapnel. After reading Clean Ruby, you'll know how to bring them all together in one place to reveal your intent.

nwmcsween 15y ago
Ok so you're the author but this statement is pretty cryptic can you expand up on how DCI would make things better than the tried and tested test -> programming -> factoring out path most programmers take? Even rails takes this model.
- rjknight 15y ago
  DCI doesn't necessarily mean fewer tests - done correctly it can make testing easier since it can help to separate concerns and allow for easy testing of discrete components. I don't think this is the killer feature for DCI though; you can do this with other OO methodologies just as well. DCI's main advantage is that it encourages you to write code that follows an "assemble the objects I need, then perform a sequence of operations on them" pattern, where the operations generally occur inside a single method. This is your algorithm, and the idea is that you should be able to read that algorithm and get a good idea of what the program is doing. Instead of relying on tests alone to verify that your program does what it's meant to, you should be able to read the code too. Jim Coplien's talk here is a good intro: http://www.infoq.com/presentations/The-DCI-Architecture http://www.infoq.com/presentations/The-DCI-Architecture
- saturnflyer 15y ago
  DCI has you split objects from their responsibilities until they are needed. This reduces your need to understad what eventually becomes (commonly in projects) massive classes with lots of responsibilities. But more so than that, in DCI you create a Context object whose responsibility is to coordinate objects and the roles they play: the Context represents your algorithm. This allows you to point to an object that is responsible for a business use case, rather than what is typically done by having methods strewn about the classes of you system with no indication of when they are needed.

nwmcsween 15y ago

Ok so you're the author but this statement is pretty cryptic can you expand up on how DCI would make things better than the tried and tested test -> programming -> factoring out path most programmers take? Even rails takes this model.

rjknight 15y ago
DCI doesn't necessarily mean fewer tests - done correctly it can make testing easier since it can help to separate concerns and allow for easy testing of discrete components. I don't think this is the killer feature for DCI though; you can do this with other OO methodologies just as well. DCI's main advantage is that it encourages you to write code that follows an "assemble the objects I need, then perform a sequence of operations on them" pattern, where the operations generally occur inside a single method. This is your algorithm, and the idea is that you should be able to read that algorithm and get a good idea of what the program is doing. Instead of relying on tests alone to verify that your program does what it's meant to, you should be able to read the code too. Jim Coplien's talk here is a good intro: http://www.infoq.com/presentations/The-DCI-Architecture http://www.infoq.com/presentations/The-DCI-Architecture
saturnflyer 15y ago
DCI has you split objects from their responsibilities until they are needed. This reduces your need to understad what eventually becomes (commonly in projects) massive classes with lots of responsibilities. But more so than that, in DCI you create a Context object whose responsibility is to coordinate objects and the roles they play: the Context represents your algorithm. This allows you to point to an object that is responsible for a business use case, rather than what is typically done by having methods strewn about the classes of you system with no indication of when they are needed.