5 ms·
Especially true if your business objects are generated code, e.g., protocol buffers. Combining business logic with business objects is a mistake. That's a text
by tantalor 10y ago
Especially true if your business objects are generated code, e.g., protocol buffers.
Combining business logic with business objects is a mistake. That's a textbook example of tight coupling.
- jbattle 10y ago> Combining business logic with business objects is a mistake. That's a textbook example of tight coupling. Isn't that a textbook example of object oriented programming? Whether OOP is a mistake in and of itself is another question ...
- tantalor 10y agoTextbook examples of object oriented programming are notoriously bad. Stuff like, Dog dog = new Dog("Spot"); dog.bark(); These are toy examples meant to quickly introduce the mechanics of objects, not teach good software engineering patterns.
- mattmanser 10y agoWhere else are the business rules of an object supposed to go? Textbook? It's what you're supposed to do! And if you say in a bloody "service", which just has the object passed as the first variable into every bloody method, I swear I'll come down there and strangle you with your own keyboard cord. That's the actual textbook definition of tight coupling. I'm working on a project which has 5 layers, business objects with no methods, a dto layer, a dal layer, a service layer and finally the website. All incredibly tightly coupled and utterly pointless. It's an utter nightmare. Every time I touch the code half of it disappears, right now I've still deleted more lines than I've added while adding a ton of functionality. That idea is so broken because it violates KISS, YAGNI and DRY all in one in a futile attempt to "decouple" things which are obviously coupled because the data is needed to perform the business rules. There's a malaise in modern programming and it's the dogmatic pursuit of decoupling over simple and clear code.