How dependency lines work in object-oriented design

When you look at an object dependency graph, it’s not 100% clear how to read it. When one object points to another, what does that mean exactly? An object is said to depend on another object in the following scenarios: When an object knows the name of another object When an object knows the name of a method of another object, and knows the arguments that method takes The first is quite easy to recognize and if you have that first dependency level, you implicitly have the second. If at all possible, you want to strive towards the second point. »

Resources to help guide architectural decisions in Rails apps

My previous post outlined a trivial example where I refactored some basic, boring business logic into a service object, or transaction script (depending on who you ask). It set off a lot of debate on Twitter and Hacker news about the topic. I was quite surprised. At the very least it means that many others have felt the pain of having rails dictate your applications core architecture. »

Where the logic hides in Rails apps

DHH recently authored a SVN blog post that advocated breaking up fat models into separate mixins that would live in a new directory in the rails structure, app/concerns. He made it clear that breaking up domain logic into concerns will make code easier »