Eating at a buffet

I finally found how to explain the advantage of Component C objects.

Using Component C objects is like eating a buffet. You have a choice of different foods which you can pile onto your plate in any combination or order that you want.

Using traditional object oriented languages/frameworks is like eating at a restaurant. You have a choice of different meals, each with its own combination of ingredients.

Using fixed meals is easier to use when the choice is small. But it does not scale. There is a reason why sandwich fast food places allow you to choose your own combination. Having a list of pre-fixed combinations becomes messy when it grows more than a few dozen options.

Thats why object oriented examples always work. They are a small selection of classes in use which work great just like a menu with 5-10 items works great as well.

Its when you have to manipulate over 50 items that things become complicated. So then they are separated into categories. But then you get to a point when categories need to be broken down into sub categories. Very quickly things can get out of hand. A complex system may have 200 classes that a developer needs to manage.

Do you derive your class from A, B, C, D, E or the other 50 options. Or maybe you go for containment which defeats the whole purpose of common components since you do not want to have to expose every possible interface that you want to support.

With Component C components. Its a buffet. You only offer a choice but do not control the combination of those choices. If the developer wants to make an object (like a plate) and attach to it (like putting food on a plate) a node and window component, you have a window that can be stored in a hierarchy of other nodes.

While I only have around 20-30 components, the advantage looks small. Its when I reach over the 100 component count that things become interesting. Every component only cares about what it needs to provide a specific feature or part of a feature. The combinations are defined by their usage. It scales.

UIWindow does not have to deal with hierarchy. CoreNode deals with hierarchy. Its separation of concerns. Components stay small because I don't have to stuff every feature I ever need in the same component.

Objects need to support reference count. Instead of stuffing it into CoreObject, it is handled in a separate CoreRef component.

As applications grow bigger, they will need to move to the buffet model. Al a carte.
Just like users are getting tired of fixed 1000 channel selections and prefer to choose what they want instead of tuning to a fixed channel that airs the show they want at a specific time.