4 ms·
> it seems to do more harm than good to their understanding good OO design. Can you provide an example?
by alisnic 14y ago
> it seems to do more harm than good to their understanding good OO design.
Can you provide an example?
- stiff 14y agoI 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.