Thank you for your perspective as a manager. I did try to reflect on “if people can’t understand on the first pass, is that good code”. However, I would also argue that by apply design patterns (judiciously), I try to make every single class ‘have one single reason to change’ (the S in SOLID). The result is having a few extra interfaces, decorators, injectors, or factories (which are 50-80 lines long each), vs a single class that is over 400 lines long which nobody understands what it does and no one dares touch it.

Keep in mind that while really small classes make it easier to understand each individual class, they make it much harder to understand the overall picture and call flow. Lots of small classes always results in a lot of indirection, which is much harder to follow.

Also, I would not consider a 400 line class particularly big. How many 50-80 line classes do you create to replace the single 400 line class? If you've created ten 80 line classes to replace the single 400 line class then you've just doubled the size of the code, not a good thing!

@17of26 I'd rather have 800 lines of readable, defended code in ten classes than 400 lines of code in one file and who knows what is reading and writing what.

There's no reason that 400 lines of code in one class can't be readable and defended.

In my opinion the S in SOLID is the most abused principle of O-O amongst zealots. It's also the most impractical, and unnecessary, and leads to ridiculous complexity at the expense of straightforward understanding. Even as a principle - and it surely isn't a law - it is an exaggeration, meant to (strongly) discourage large, unorganized, kitchen sink classes - as commonly programmed by beginners to O-O. But "Single" is far too strong in practice, and the resulting code is frequently less understandable, less maintainable, and less extensible too (due to lack of understandability).

@davidbak The S in solid (standing for "Single-Responsibility Principle") does not mean the class has one method or one function, but one job. In the air of Domain-Driven Development, that means it handles one aspect of the bounded context, which may be the whole bounded context. Things like "load a bunch of users and filter out the invalid ones" can be one job. You can have 400+ lines of code that have one job. The problem is people don't know how to define "job", or where. They think "this is the factory" is the only job this can do, without thinking of other parts of it.

@rexcfnghk-There's only 2 things more important than "easy to understand" when it comes to code. "It works" and "It's on time". Your putting the 'S' above "easy to understand" is a big mistake. If one were to prioritize "easy to understand" then you wouldn't have a 400 line class that nobody understands. You might have a 400 line class but it would be easy to understand. If you want to improve your company's code then push for easy to understand. It will provide much more value to your company and will make you a far better developer than attempting to blindly follow fads of questionable value

@17of26 - 400 lines is big if it's a frequent occurrence. My last project has only 4 classes 400 lines or bigger (it is big & complicated). 3 of them are coordinating processing with various 3rd party hardware, so it makes sense to lump all those into big classes. The other helps make it easier for the half-dozen external control interfaces used to monitor and control the system to have a common API. This project is adhering to the "easy to understand" principle while being easy to change and applies appropriate design patterns. Good SW can be done without using esoteric/bloated patterns.

+1000 for being practical over these supposed "best practices." I've never seen them help anything. Small nitpick: "SQL" is not a database technology comparable to Oracle. The name of Microsoft's database is SQL Server. Pet peeve of mine, since calling it SQL may mislead some people about Microsoft's relationship with the language's standard. I've certainly seen where their tendency to prefix SQL Server classes in their client library (the ADO.NET one) with just "Sql" makes the classes appear vastly more general than they are.

Also, an alternative you might want to add is working on a story where a code base did change without these layers and it was a nightmare to fix. In that context, the OP could present the patterns as a potential solution to try.

@jpmc26: Some use "MS SQL" (a slang term) for "SQL Server", even in job adverts. "SQL" may be a shortened form of "MS SQL" (though I have no evidence whatsoever).

@202_accepted - you're right about Single Responsibility but check out almost any blog you read - the examples they give are not your own "job" idea - you're right about how (plenty of) people misinterpret/misunderstand that.

I'm with @jpmc26 "the younger generation" referring to Microsoft SQL Server as "SQL" makes my blood boil too. In the early '90s the only SQL database MS had was Access. I believe they licenced the original SQL Server technology from Sybase. Whether that's true or not, MS were very late (over ten years) to the SQL database party and calling their (very fine) offering "SQL" leads the clueless to think that Microsoft invented the programming language. TL/DR - Please change "SQL" to "Microsoft SQL Server" - it'll stop the old fogeys from complaining.

Nowhere in the tenants of SOLID does it say to use as many design patterns as you can and throw factories and decorators everywhere. Even if you did: you can use the "factory" pattern in one line: () => new Foo(). A lot of straw-man arguments are happening here. Following SOLID and other good design principles has always resulted in both smaller classes AND less code overall for me.

"[factories, providers, injectors and whatnot] do have a place in arrangements that are highly volatile" - even this is questionable. These kind of hooks for extension and modification make the particular kind of changes and additions they're suited to easier, at the cost of increasing the total amount of architecture and therefore the amount of reading, comprehension, and raw typing needed to make other changes. When the management situation really is one of chaos, and I feel helpless to predict what my orders will be tomorrow, I try to minimise code, not maximise hooks for extension.

"They generally are set up for things that will never really happen" Like unit testing?

@davidbak: +1, I've seen code where simple user authentication needs to go through 9 levels of abstraction. It literally takes several hours to go through all the middleware to do what should have been 1-2 lines of code.