What is a good architecture / design pattern for giving multiple shared attributes in different combinations?

Question

I have a need for many different objects to have various combinations of attributes. For a demonstrative example, a flaming dog would have a dog attribute, a flame attribute, and a tail attribute, while a water cat will share the exact same tail attribute but have its own water and cat attributes, which it also shares with others, etc. Each attribute has complex behaviors and completely unique methods that I would want to store in a class for each, and there will be many different combinations of these for each of the various objects.

I then need to be able to count up the number of each attribute constituted in the current application, and then use the unique methods within each represented class based on the number. In the above example, I would use the flame attributes unique methods with value 1, but the tail methods with value 2.

Is there a good architecture for organizing these attributes on each of the objects? My first thought is to just give, for example, each flaming dog a member variable for each of type flame, tail and dog. Then I can iterate across all objects and count up repeated attributes, and access the methods on any of them with the final tally. But with this, I will have many unused attribute objects which are only instantiated to end up in a count, and otherwise completely redundant.

I could also have all of the attributes be singletons and have the objects hold a reference to them, but then I would always have to have all of the many attributes instantiated at all times and handled as globals so that I can have their attributes at the ready to be pointed to, which also feels like overkill and wasteful in its own way.

Is there some design pattern or architecture that accomplishes a more efficient way to handle this? Sorry for what is probably a fairly common question, but I wasn't sure how to search for an answer to this without typing up this whole essay.

Answer 1

Yes there is. It is called the entity component system. It is used mostly in gaming industry to avoid deep hierarchies and share "components" (attributes or behavior or both) between "entity" objects dynamically, preferring composition over inheritance.

Answer 2

The basic approach for specifying arbitrary data fields arranged in arbitrary shapes, and for implementing algorithms which perform processing upon those fields and shapes, is nowadays called "writing software" or "software development". That's potentially how general your question is.

There are a number of software platforms that have the concept of "reflection", which allows metadata about the software/source code to be retrieved and processed at runtime. So for example, having already specified a number of fields in the source code, you can then enumerate these at runtime.

I'm unclear what a "flaming dog" or a "water cat" is in the real world, or why a computer would be applied to record things about such creatures. There is a risk here, I think, that you've wandered off into a fantasy land and have lost touch with the real world of examples that might demonstrate your point. Your question therefore presents as a strange mixture of childlike imagination and the serious professional jargon of a practitioner, and it's not clear in which role you ask the question.

I suspect what you're really getting at is how to record information about things whose categorisation cannot be reconciled with a hierarchy.

For example, in the standard biological taxonomy of animals, you have (amongst other things) mammals and birds. So you have say mice and pigeons, which fall nicely into one or the other in the standard scheme. But then you get bats, who have both tails and wings.

It's important to remember that the animal world is not a product of intelligent design, and the scheme itself is an invention of academic biologists to suit their purpose of study and reproduction of human knowledge (rather than designed for the convenience of fully routinised/computerised data processing).

Attempts at all-conquering information systems in healthcare often have this problem, because they find that different departments have a different idea of what a patient is and what things need to be recorded about them - a specialist department in conjoined babies, for example, has a different idea than most other departments (who may handle a conjoined case in a purely ad-hoc way, rather than design all clerical routines around the idea that two patients may be physically indivisible, or that one patient may have two names and two bodies).

Basically there can be different schemes of classification for different purposes, and (as an aside) one of the reasons why relational databases do not have a fixed hierarchy of tables is because no one hierarchy suits all purposes, and the database programmer will often employ different or ad-hoc hierarchies when querying data.

In OO programming, two standard approaches to non-hierarchical schemes are composite objects (I'm not using the word "composite" in any technical sense - I just mean an object that is composed of parts which it organises together) or polymorphic interfaces.

A third possibility is to use simple dictionaries of attributes (key-value pairs) on each object, but you potentially lose the benefit of data type checking and various other standard compile-time features.

The reason why non-hierarchical schemes are relatively troublesome for programming languages are because programming languages intrinsically use defined hierarchies to express field membership and to perform certain kinds of navigation.

Often, if it isn't necessary to accommodate a non-hierarchical scheme - which makes both the software design and the ongoing usage far more labour-intensive - then it's easier to design a computer application around a hierarchical scheme. So in that sense, a fourth approach to non-hierarchical schemes, is to design them out, and instead design a hierarchical alternative if possible.

A common approach of bureaucracies that have to handle a certain amount of real-world complexity which can't be reasonably reconciled with computerisation, is to have the computer software handle the mainstream of cases, but to also have "paper cases" where a skeleton of information is put into the computer but the majority of administration occurs using paper files using human expertise and flexibility.