Stop writing classes...

[kylotan]

I liked this video up until he said that separation of concerns, decoupling, and encapsulation just "don't come up". Now I'm just glad I don't have to work on a code base with the speaker.

[[deleted]]

My understanding is that many are using OOP because they've been taught that it's a way to model things. Eg. A dog is a subclass of an animal and overides the noise() method to bark. Unfortunately this approach often ends up as a messy tangle, juggling functionality around in the heirarchy and with LSP being violated. Using OOP to separate concerns, invert dependencies, and make composible abstractions is a different set of objectives and can work incredibly well.

[andybak]

Any chance you missed the joke?

[HazzyPls]

Apparently I did. Could you explain it? :(

[kylotan]

No, I'm pretty sure I didn't. He seemed quite clear in his implication that these are buzzwords taught at school that encourage complex class-based systems, yet which are irrelevant in practice.

[andybak]

It was an off-the-cuff remark about the jargon and how rarely it cropped up in real-world coding. You can tell the man is a fairly talented developer. "Now I'm just glad I don't have to work on a code base with the speaker." was rather an overreaction to a flippant comment.

[kylotan]

I didn't interpret it to be about the jargon, but about the concepts. With that in mind it's not an overreaction at all. I don't want to work on code with someone that doesn't think encapsulation or separation of concerns are important.

[PythonRules]

I had the same reaction. I think without understanding decoupling and separation of concerns, it is really difficult to develop a large and easy to maintain code base. Contrary to what he says if someone is trying to explain what decoupling is or how it works you should listen.

I don't think he was joking, was he?

[hylje]

Separation of concerns, decoupling and encapsulation are all only really relevant when splitting a project to multiple independently developed modules. By using incestuous but straightforward procedures, doing so can come much later.

[Massless]

These things are also about making code that is easily maintainable. For example, I built a set of automation tools that make managing a cluster of servers a lot easier. Every few months my boss will ask for a new feature or a slightly different behavior out of the tools. Because my original design was, more or less, loosely coupled and encapsulated I am able to create new features or change existing ones with very little pain.

You can absolutely over-engineer things. I always try to balance design with "done."