Sign in to follow this  

What is the composition version of OOP shapes?

This topic is 484 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

 

Share this post


Link to post
Share on other sites

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.

Edited by Hodgman

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

This topic is 484 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this