5 ms·
This article describes the OOP approach that leads to object-relational mapping, boilerplate code, database schema duplicated in code, navigational data access
by reaanb2 1mo ago
This article describes the OOP approach that leads to object-relational mapping, boilerplate code, database schema duplicated in code, navigational data access and the impedance mismatch. It defines OOP around data modeling and taxonomy, rather than around responsibilities. Principles such as "Tell, don't ask" and "Single responsibility" are just ignored. What responsibility does a book have in a library management system? It doesn't, it's just a subject of recorded facts, and a better approach would be to identify the behavioural components of the solution space, construct those as classes/objects, and let facts be encapsulated in or communicated between objects.
- omnibrain 1mo ago"Object thinking" by David West was eye opening about this back in the day. The gist is to model the objects not along the line of real world entities, but along the line of "behaviour" like you mention.
- bcrosby95 1mo agoYes, OOP is hard to do right. It's not helped by examples and schools largely teaching from real world nouns. Most people in OOP languages are writing procedural code. For all these reasons I just skip it. I still use OOP languages, but I leave the OOD at the door. For what it's worth, you can get all that with plain old C. Declare structs up front. Allocate them all as pointers. The C file is the class, and has the actual definition of the structs. Strangely enough, in a sense, OOP languages makes it harder to do this than in C. Not that C doesn't have other flaws.