4 ms·

I think the importance of the Single Responsibility Principle is much overestimated by many people and introducing terms like "single-responsibilty objects" for

by stiff 14y ago

I think the importance of the Single Responsibility Principle is much overestimated by many people and introducing terms like "single-responsibilty objects" for what are essentially simple procedures is symptomatic of this. There are many properties of classes one can consider beneficial, but they might in fact conflict with each other to some extent, especially when carried out to extremes like in this case, so what you want is to find a good compromise. The "principle" itself is rather a very fuzzy guideline, so I wish it wouldn't be taught to people since it seems to do more harm than good to their understanding good OO design. On another note, I wonder to what extent Rails usage of the Active Record pattern makes "models" so clumsy in large applications. It works great to a certain point, but maybe in large applications the Data Mapper pattern (not to be confused with the DataMapper library) would help to isolate a large aspect of what currently goes in a model while keeping a nice OO interface: http://www.martinfowler.com/eaaCatalog/dataMapper.html http://www.martinfowler.com/eaaCatalog/dataMapper.html

alisnic 14y ago
> it seems to do more harm than good to their understanding good OO design. Can you provide an example?
- stiff 14y ago
  I heard this principle referenced in the context of objects such as presented in the post quite a few times already, for example there was a heated discussion here: http://news.ycombinator.com/item?id=4013807 http://news.ycombinator.com/item?id=4013807 I explained back then why I consider this not object oriented at all. Here I just wanted to say that if you imagine a spectrum of all the possible breakdowns of a problem into classes, with one huge class at one end and a breakdown so granular you have a separate class for each operation of the system on the other end, there is a point where making the classes have less responsibilities and having more of them is no longer beneficial to the overall design, because you start to violate many other basic principles, for example the "objects" don't really encapsulate any data anymore. I think finding the sweet spot here is the kind of skill that is learnt with experience and not easily passed on with words, hence the wording of the principle is so fuzzy.
programminggeek 14y ago
ActiveRecord is certainly a huge part of the problem and it is the first thing to decouple from your models. However there is a wonderful benefit to making since action objects - you can cleanly do dependency injection without side effects on the rest of your service. That makes testing them much cleaner and more obvious. The other really cool thing you could do is wire actions together with different sources. That could make things like data migrations between different data sources trivial or adding caching to smaller slices of your system easy.

by stiff 14y ago

alisnic 14y ago

> it seems to do more harm than good to their understanding good OO design. Can you provide an example?

stiff 14y ago
I heard this principle referenced in the context of objects such as presented in the post quite a few times already, for example there was a heated discussion here: http://news.ycombinator.com/item?id=4013807 http://news.ycombinator.com/item?id=4013807 I explained back then why I consider this not object oriented at all. Here I just wanted to say that if you imagine a spectrum of all the possible breakdowns of a problem into classes, with one huge class at one end and a breakdown so granular you have a separate class for each operation of the system on the other end, there is a point where making the classes have less responsibilities and having more of them is no longer beneficial to the overall design, because you start to violate many other basic principles, for example the "objects" don't really encapsulate any data anymore. I think finding the sweet spot here is the kind of skill that is learnt with experience and not easily passed on with words, hence the wording of the principle is so fuzzy.

programminggeek 14y ago

ActiveRecord is certainly a huge part of the problem and it is the first thing to decouple from your models. However there is a wonderful benefit to making since action objects - you can cleanly do dependency injection without side effects on the rest of your service. That makes testing them much cleaner and more obvious. The other really cool thing you could do is wire actions together with different sources. That could make things like data migrations between different data sources trivial or adding caching to smaller slices of your system easy.