Manager: This code you wrote violates the single responsibility principle!!

Dev: How so?

Manager: You have one function that you call in *MULTIPLE* places. That’s too much responsibility for one function! Functions should only have one responsibility!! Creeping the scope of a function beyond that is a TERRIBLE way to write code!

Dev: But why spin up multiple functions that all perform the same thing?

Manager: Well if a function has a bug in it and you use that function multiple places then that bug exists everywhere you use that function. If a function only has one responsibility then if it has a bug that bug will only exist in the single place it is called! You really should think first before asking questions like that.

Dev: …

Seeing OOP classes with more than a 1000 lines of code really pisses me off.

Dev: There’s a file in your PR with over 1000 lines of code, I think it should be broken apart into a couple smaller pieces to be a little more in line with the single responsibility principle

Muppet Dev: That file only has one responsibility! It can’t be broken apart!

Dev: How’s that?

Muppets: It’s single responsibility is managing that group of functionality

Dev: …

Best practice of the day:
Single responsibility principle - One class should be responsible for everything!

Either that or someone was payed for LoC. 😁

This class adheres to the single responsibility principle: it is singularly responsible for the entire application.

Whywhywhywhywhywhywhywhy?

Why one would put all 30+ menu items in mixin??! Please do tell.

I just read Robert Martin's chapter on the Single responsibility principle in Clean Architecture.

In it he explains that stakeholders, or actors, that require their own functionality that may be similar to others should have separated code. This is because 2 actors == 2 potential reasons for change.

But this seems to run counter to DRY. Am I mistaken?