Hi all

First of all are components and composition the same thing? - I'm talking components as in the gamedev sense, a health component a position component...?

Also early on in C++ I was taught the usefulness of inheritance using the 'shapes' demo e.g. a base Shape class and then derived Shapes such as a Square or Triangle that have their own lengths and areas.

I am wondering if there is a composition based version of this same demo?

And is there a version of this demo that uses component based programming?

I think I am getting composition and components confused...

Thanks all

Component-based programming is a method that relies on composition :)

Composition == the act of building larger things out of smaller parts.
Component == a small part.

In OOP, the term "component" is informal language. A "class" (a formal term) could informally be called a component. When a class contains another class as a member, you've composed the smaller class/component into the larger class/component.

In other paradigms, a "component" may be more strictly defined.

I am wondering if there is a composition based version of this same demo?

The same, but delete the Shape class and don't use inheritance :lol:
Also note that these kinds of examples are often ok for teaching you how to use the tool -- the syntax of inheritance in a particular language -- but are often terrible for teaching the why. OO inheritance must obey the Liskov Substitution Principle, meaning that any algorithm that works on a Shape, must also work perfectly fine on a Triangle or a Square. May of these beginner level teachings on inheritance do a terrible job of teaching, and actually present examples that violate the LSP...

So for the inheritance version of the Shapes class to even make sense to begin with, you need to first have an algorithm that works exactly the same way on Triangles and Squares. If you design your classes before that algorithm is known, then you're doing it wrong.

I was actually trying to think of a case when it would be useful to deal with primitive shape classes polymorphically. I've done stuff like derive CircleCollider and AABBCollider from an abstract Collider before, but not just for raw shapes without some kind of unifying functionality. Maybe just derived from some render-object base class that would be more like an interface.

Even with the colliders it turned into a bit of a mess after enough derived types were added. Each derived type had to have an explicit collision test for each other derived type. In the end the only thing the added complexity bought me was that I could put a collection of various Colliders in a single container on an entity, but it occurred to me later on that I would have been better off just using a composite class with POD struct colliders. :P