Decomplecting means using IDs

If you're going to decomplect a class into a bunch of component slices, you're going to need a way to tie those slices together. You need identifiers that you can use across multiple systems. So you'll be using a lot of globally-unique identifiers and hashmaps (or other lookup tables).

Examples:

• Entity Component System: in true ECS, game objects are decomplected into Entities, Components, and Systems. An entity is just an ID (or a position in an array). The ID is used to get component data structures and pass them to systems.
• Database normalization: normalization decomplects a record into tables, and foreign keys are what let you join them back.
• Decomplecting actors

Benefits:

• Each decomplected slice does one thing. This clarity of purpose often leads to a more correct implementation, as well as performance optimization opportunities.
• You don't end up re-implementing. For example, you can build a name system once, and use it everywhere you need to dereference a name. You can build a queue once, and use it everywhere you need queueing semantics.
• Decomplected slices are decoupled, making it easy to swap out implementations.
• The boundary between slices is typically just an ID and some data, so you can swap for any backend that can consume that shape. You can even address things across network boundaries.

Tradeoffs:

• You now have a lot of related, but decoupled resources that you need to manage. You have to enforce invariants with code (e.g. delete all resources for an ID together). This is usually done by a system that coordinates the decomplected slices.
• Layers of indirection. ID-through-hashmap is going to be slower than memory pointer. But then again, Python builds its whole class abstraction on top of this kind of hashmap indirection.

Related

Decomplecting, Functional programming