[sharpercoder]

This boils down to code removeability. A few larger classes wit large methods is in general easier to remove/refactor then a large amount of small cohesive classes with an obtuse design concept behind it. Of all the codebases I refactored, I take the "large methods and large classes" hands down. Pulling a few classes here and there is easy, compared to first understanding a clusterf*ck of overengineered abstractions.

[ljm]

I worked with a domain driven setup at one point, which seemed like it was designed to sell JetBrains licenses because it became almost unbearable to try and maintain the codebase with a text editor. You would have to go through a controller, a DI container, a repository, an entity, a factory, a builder, maybe a facade, and an event bus... almost all of which were single-method classes (except for the DI boilerplate which was split between constructors and YAML files) that just called the method of the next dependent class. One line of concrete business logic hidden between half a dozen files full of architecture.

The rationale was that the abstraction was necessary to make things easier to replace if they weren't needed but it was a false assertion on two levels (and it almost always is):

- that kind of replacement is unlikely to happen in the short/mid-term, and if it does it won't be in a way you anticipated.

- the simple version could be deleted and rewritten in less time than it would take to fix your highly abstracted/decoupled/meticulously architected integration

Of course, simple isn't easy and this approach to abstraction (where you take classes/methods longer than x lines and extract them into more classes and methods) is very easy to achieve... at a great cost.

[greggyb]

This makes me think of a good thinking talk, with a quote I pull out from time to time:

> I hate code, and I want as little of it as possible in our product.

http://pyvideo.org/pycon-us-2012/stop-writing-classes.html

[milesvp]

I was always disappointed I couldn't find more talks by Jack Diederich after watching this one. His approach was so practical compared to so much programming advice out there. I see now that he's got a few more talks linked from here.

I know how I'll be spending a few hours in the next few days. Thank you for reminding me of his talk!

[Silhouette]

Indeed. I am always surprised/amused by how often someone will go to the ends of the earth to criticise big up-front design and proclaim that you ain't gonna need it, but then routinely set up several layers of indirection and abstractions in the most basic code, frequently for no immediate benefit other than letting their similarly complicated automated test suite run.

[ltrcola]

As long as we acknowledge that large classes with large methods can also cause problems. Dealt with that before and it is not fun by any means. The worst offenders, though, are the projects that have a LOT of large classes with large methods, plus some crazy abstraction thrown in like a dash of pepper.

[flaviojuvenal]

code removeability, or, write code that is easy to delete, not easy to extend: https://programmingisterrible.com/post/139222674273/write-co...