jferris

Agreed on method extraction; overuse will just introduce more hoops to jump through when trying to understand the code. Unless you're moving methods to other classes, though, you can avoid adding entry points to the API by extracting methods as private. We use private methods to reveal intent, break down large methods, and reuse behavior within a class.

Also agreed on Null Object. I tried to make it pretty clear in the chapter that it's not a one-size-fits-all kind of solution and must be used with care. I strongly advise against using is_a?, ===, or case statements to check for null objects.

You can define present? to be false on your null class if you NEED to check for a null object, but the pattern is only useful when the higher level code (views, etc) don't need to care about whether or not the object is null. If you have to add present? checks to everything, I'd advise against using null objects.

The book is also trying to highlight that "middle way" you're talking about. Each chapter tries to outline the benefits and drawbacks of using a particular approach. We've stressed that you don't need to "fix" every code smell you find, and that the solution depends on the specifics of an application. The book is designed to give developers a better understanding of the methods for finding and fixing problems, and the solution chapters try to give the developer the ability to decide what the best solution is for a specific situation, rather than trying to achieve an "if x then you always y" kind of approach which doesn't work in the real world.

It won't affect production performance. It syncs copy in the background, so no requests to copycopter.com are performed during requests to the client application.