A Thought on Separating Behaviors from Data

Allocators are discouraged to be stateful. If we want to implement a memory pool or an object pool, we may separate the pool itself from the allocators. This inspired me that it is a ubiquitous pattern across SE.

Deep-inheritance and binding states with actions are being more and more discouraged nowadays because in many cases this does not seem to improve efficiency nor maintainability. It also induces inconsistency in behavior of the same interface, losing necessary information to do optimizations.

So here comes another way: Separate the data from the behavior.

From the Visitor pattern to the ECS pattern, this idea is being applied more and more widely.

A very easy pattern could be like this: by providing basic implementations concerning most about the lower levels, such a low-level facility provides interfaces that mostly expresses the functionalities of it and put the ease of use as second thought. Higher-level wrappers such as allocators can define sets of behaviors on them (data). Perhaps they should not be called "wrappers" any more? lol.