3 ms·
Thanks for the examples shoehorning data hiding into ECS! They are revealing even if only appropriate in esoteric circumstances. > But you also aren't asking
by rectang 6y ago
Thanks 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".