5 ms·

"One of the properties of good OO design is that code that operates on data is located close to the data." Says who? I say the point of good OO design is to h

"One of the properties of good OO design is that code that operates on data is located close to the data." Says who? I say the point of good OO design is to have very clear focused responsibilities for classes, very clear layers of abstraction, and concretely declared dependencies. This way I know my business logic doesn't sprawl, is discoverable, can be replaced modularly, and tested extensively and throughly. This author sounds like he has no idea what it takes to actually build a maintainable code base of domain-driven business logic. The fact that he actually thinks "Order.SubmitForPicking(), UserAccount.UpdatePostalAddress(), and Basket.CalculatePriceIncludingTaxes()" are examples of good OO design is LAUGHABLE. This approach couples your data layer with your business logic, negates the ability to use mocks, and makes refactoring WAY harder than it needs to be.

markbnj 11y ago
Well, encapsulation was one of the three legs of the OO stool, especially at a time when languages like C/C++ offered no protection against reading/writing memory anywhere in a program's data or code segments. Encapsulation back then literally meant keeping the representation of the data close to the code, i.e. in the same class that implemented the interface on the data or a closely-related specialty class. So I would say the author is not incorrect in looking askance at "value objects" that are passed around, from that perspective. On the other hand, I'm not sure the perspective is quite as important as it used to be. Modern dynamic languages make it harder to do bad things in memory, and passing value objects around is pretty much the arterial life force of the entire Internet. In any case one thing is sure: the more pieces of code that know the internal structure of a bit of data the more dependencies there are, and the harder the program is to work on. So to the extent you can have that knowledge in one place - the implementation of an interface - you're better off. Perhaps more importantly, OO purism just seems a little anachronistic to me today. I think the key things that OO had to teach us have been mostly absorbed, and we've moved on. It's still there, but now it's part of the fabric of the art and not as obtrusive as it was in the 90's.
- usrusr 11y ago
  OO concepts live on whenever we are talking about interfaces, contracts and the like. The failed experiment is "true" object oriented domain modeling, the idea that software representations of real entities (an order, a dog, a car) should include code beyond maybe some basic constraint checking. Other than that, thehe OO tools are still powerful and some form of encapsulation is essential for any data structure that is more complicated than a pain array or a one-way linked list. But these structures are not representations of real objects, they are actual data objects. A hashmap isn't a representation of a hashmap, it is the real thing (even if it maps representations of dogs to representations of cars).
usrusr 11y ago
Sorry to nitpick: the point of OO is exactly what the original rant was advertising: compile your domain representation into furry little blackboxes that live inside the computer and interact with each other. Your point (and the HN hivemind consensus, because even the FP purists will agree) is that OO tools are better used in ways that do not follow the OO design principle.

markbnj 11y ago

Well, encapsulation was one of the three legs of the OO stool, especially at a time when languages like C/C++ offered no protection against reading/writing memory anywhere in a program's data or code segments. Encapsulation back then literally meant keeping the representation of the data close to the code, i.e. in the same class that implemented the interface on the data or a closely-related specialty class. So I would say the author is not incorrect in looking askance at "value objects" that are passed around, from that perspective. On the other hand, I'm not sure the perspective is quite as important as it used to be. Modern dynamic languages make it harder to do bad things in memory, and passing value objects around is pretty much the arterial life force of the entire Internet. In any case one thing is sure: the more pieces of code that know the internal structure of a bit of data the more dependencies there are, and the harder the program is to work on. So to the extent you can have that knowledge in one place - the implementation of an interface - you're better off. Perhaps more importantly, OO purism just seems a little anachronistic to me today. I think the key things that OO had to teach us have been mostly absorbed, and we've moved on. It's still there, but now it's part of the fabric of the art and not as obtrusive as it was in the 90's.

usrusr 11y ago
OO concepts live on whenever we are talking about interfaces, contracts and the like. The failed experiment is "true" object oriented domain modeling, the idea that software representations of real entities (an order, a dog, a car) should include code beyond maybe some basic constraint checking. Other than that, thehe OO tools are still powerful and some form of encapsulation is essential for any data structure that is more complicated than a pain array or a one-way linked list. But these structures are not representations of real objects, they are actual data objects. A hashmap isn't a representation of a hashmap, it is the real thing (even if it maps representations of dogs to representations of cars).

usrusr 11y ago

Sorry to nitpick: the point of OO is exactly what the original rant was advertising: compile your domain representation into furry little blackboxes that live inside the computer and interact with each other. Your point (and the HN hivemind consensus, because even the FP purists will agree) is that OO tools are better used in ways that do not follow the OO design principle.