5 ms·
Centralised memory management doesn't inherently conflict with a decentralised OO design. If you refactor your object construction into factory functions, you
by MattHeard 8y ago
Centralised memory management doesn't inherently conflict with a decentralised OO design.
If you refactor your object construction into factory functions, you can make the factory responsible for implementing the memory management, and the objects themselves responsible for implementing the memory use. The objects can be ignorant about the handle array. The objects can delegate any memory-related functions to the factory methods.
- Koshkin 8y agoBut the factory pattern has nothing to do with memory management, it serves a different purpose; memory management is a separate concern.
- EpicEng 8y agoIt's an abstraction used to create objects and manage their lifetime. There is no inherent opposition to managing memory in that pattern. Also, it's been done before and it works, so what is the issue specifically (i.e. not some religious nonsense about separation of concerns)?
- maccard 8y ago> If you refactor your object construction into factory functions Given this article is about c++, no need for factory patterns or anything like that. You can overload the new operator on a global, and a per type basis and do it that way.
- majewsky 8y agoA potential problem with "operator new" is that it you can only have one allocator per type for the entire process. When you explicitly pass a factory, you can have separate factory instances.
- AstralStorm 8y agoOr if you template your types on an allocator, like STL does in some cases.
- bo1024 8y agoAgreed that there's not an inherent conflict, but it seems the author is also arguing against an OO kind of design. In typical OO, all components of a given object are "owned" by that object which provides an interface through which they are accessed. This article seems to propose that the different components of an object are owned and accessed via different systems.