3 ms·
You aren't missing anything. But you also aren't asking yourself the meta-question "what is the point of data hiding?" The answer to that meta-question is "to
by neutronicus 6y ago
You aren't missing anything. But you also aren't asking yourself the meta-question "what is the point of data hiding?"
The answer to that meta-question is "to preserve assumed relationships between data." `std::vector` stores a capacity, and that capacity damn well better correspond to the length of the last array it allocated or you will get a segmentation fault. So you hide it.
The OO thing that ECS is pushing back against is a tendency to group things together solely because they are in one-to-one correspondence, when they are otherwise unrelated. In a game, there is no constraint that needs to satisfied between a player's HP and their position on the map. So why "hide" this data together in an aggregation?
If you want to permit only a few functions to operate on your big array 'o stuff, you can always do something like
class sensitive {
static allowed_operation(sensitive& s, context& c);
private:
double here[N];
int be;
bool dragons;
};
Similarly, if you need to do some really complicated computation on everything about a player, you can define Objects as aggregations of indices into the arrays 'o stuff (where typically people think of an Object as a big-ass struct of structs, often implicitly due to Inheritance), where the data you care about hiding is not the stuff from the array, but the indices:
class Player {
GetComponent() { return arrComponent[index]; }
private:
size_t index;
};
- rectang 6y agoThanks for the examples shoehorning data hiding into ECS! They are revealing even if only appropriate in esoteric circumstances. > But you also aren't asking yourself the meta-question "what is the point of data hiding?" My answer to that question has always been that data hiding is necessary for the sake of modular independence in large systems. This is a principle which applies across all of engineering, not just software — see the "starter motor" example elsethread. Implementation details need to stay hidden so that you need only concern yourself with local effects when making changes — instead of needing to keep the entire system in your head because any change might impact any tiny detail anywhere at all. Nevertheless, I agree that in some circumstances it makes sense to expose the data structure as an API, and that ECS offers a compelling approach and set of conventions as to how you would go about that.
- adamnemecek 6y agoYou are right, it's shoehorning. That's because data-hiding just isn't as much of a concern in ECS. In ECS the things you talk about are achieved differently. In ECS, implementation details are local to the systems that process the relevant data. You don't store implementation details in the data you pass to the higher abstraction.
- dpc_pw 6y ago> My answer to that question has always been that data hiding is necessary for the sake of modular independence in large systems. Yes. But not on a granularity of every object. Just like you don't put a padlock on every pocket, to protect your left hand from grabbing stuff from a right pocket. Hiding data has a real cost, just like inventing abstractions and interfaces for every tiny thing. That's the core reason why OOP-software is so bloated and always feels so "heavy". The right granularity is much coarse: modules, API layers, data-stores. Much closer to service in "micro-service", than "object".