I've been going through the book all day long, but I'm not too enthusiastic about it. It focuses so much on the "coding" that it seems to transcend the human as

I've been going through the book all day long, but I'm not too enthusiastic about it. It focuses so much on the "coding" that it seems to transcend the human aspect of it, that is, there will be developers that are not able to properly split classes, there will be teams, there will be incorrectly shaped boundaries, time constraint and even language limitations. The book seems to be great at doing an incredible analysis of an OOP language, but it doesn't seem to consider the fact that the human portion of it matters a lot. Sometimes generalizing the code so that it supports all use-cases is more expensive than just rewriting the part of the code that will change. This statement is what feels my thought as I read through the book. And even in the analysis, it seems to focus on the ideas, but not why (and numbers) that brought to this. I bring a simple example. I have no idea what this class does: class Foo < Bar end I know exactly what this one does: class Foo def initialize @bar = Bar.new end def something @bar.something end def whatever @bar.whatever end end With the tools you described, it makes sense, you can achieve this, but without them, the problem becomes serious. The "advantage" of the first one is that when Bar changes its public interface, Foo will change too. I don't think this is a good idea. It's nice you have to write less, but whenever a public interface changes, it should break things. Then again, I definitely didn't write a book or have any numbers. I'll keep going through the book, but it's been quite frustrating. Very academic, so I have to skim chunks of it.