That this one component being object orientated is necessary and good design.
We have uh interfaces, theyre contracts.

Spoiler: it wasn't, I could have written it in half the code and half the time. But no, we gotta have those patterns, can't miss on dependency injection!

Pure OOP makes a lot of problems bigger than they are. imo

Usually those rules makes a lot of sense in the long run imo

Using the same pattern everywhere ensures every developer knows where to look for something and how to add/remove/change features.

What you're talking about can be quite precarious: I might believe that converting between RGB and HSL could be done with a simple utility function since it's just a formula with one input and one output, but someone who worked with different colour spaces a lot would argue we should use a class to provide the service, so we can easily swap sRGB for ROMM RGB through the entire app if needed.

If we sit around and discuss it, we'll waste more time than either implementation would take, and if we don't discuss it, we might each implement it our way. Neither of these options is good, so it's better for the codebase and developer efficiency to stick with a set of fixed architecture rules even if it initially takes more time to do it.

Theory vs Practice.

You can turn any project into a nightmare when you overthink problems and overengineer.

If you just do what's necessary this shouldn't be a problem.

What @hitko said - if you discuss things, gather perspective and then decide in a team, you find the best solution.

All for keeping it simple but most of the time people are under pressure and either can’t go back and refactor or don’t realise it’s time to.
Small simple or short lifespan stuff has a tendency to grow.
So I prefer using the patterns like dependency injection from the start.
That and it makes doing TDD easier.

I see a lot of comments about how common patterns make sense, and they do.

But this isnt that case, see https://devrant.com/rants/4497101/...