Composite, component and entities in C++ game engine -

i'm working on school project developing game. use engine made 1 of teams have. build-up of engine unclear me , seems anti-pattern. however, seems no 1 can make design choices clear me. engine supposed use "component-based" design don't see it. below code of both component, composite , entity class. question in short this: is code using valid design pattern or overcomplicated sake of 'implementing design pattern', thereby causing antipattern?

component.cpp:

#include "engine\component.h" #include "engine\composite.h"  component::component(composite* parent)  {     this->parent = parent; }  component::~component() { } 

entity.cpp

#include "engine\entity.h" #include "engine\game.h"   entity::entity(composite* parent):composite(parent) {     this->mass = 1;     node = null; }  void entity::update() {     composite::update();      this->angularvelocity += this->angularaccelaration;     this->orientation += this->angularvelocity;      this->accelaration = (1 / this->mass) * this->force;     this->velocity += this->accelaration;     this->position += this->velocity;     if (node != null)     {         this->node->setposition(this->position);         this->node->setrotation(this->orientation);     } }  void entity::draw() {     composite::draw();      if (node == null) return;     if (!this->visible)     {         this->node->setvisible(false);         return;     }     this->node->setvisible(true);      this->node->render(); }  void entity::createnode(std::string modelpath) {     // mesh     irr::scene::ianimatedmesh* mesh = game::getscenemanager()->getmesh(modelpath.c_str());      // create model entity     this->node =  game::getscenemanager()->addmeshscenenode( mesh );     this->node->setmaterialflag(emf_fog_enable, true); }  entity::~entity() {     composite::~composite();     if (node != null)     {         node->drop();     } } 

composite.cpp

#include "engine\composite.h"  composite::composite(composite* parent):component(parent) { }   composite::~composite() {     (std::list<component*>::iterator = components.begin(); != components.end(); ++i)     {         delete (*i);     }     components.clear(); }  void composite::handlemessage(unsigned int message, void* data) {     (std::list<component*>::iterator = components.begin(); != components.end(); ++i)     {         (*i)->handlemessage(message, data);     } }  void composite::update() {     (std::list<component*>::iterator = components.begin(); != components.end(); ++i)     {         (*i)->update();     } }  void composite::draw() {     (std::list<component*>::iterator = components.begin(); != components.end(); ++i)     {         (*i)->draw();     } }  void composite::addcomponent(component* component) {     components.push_back(component); }  void composite::removecomponent(component* component) {     components.remove(component);     delete component; } 

and next piece of code player.cpp using both composite , entity hybrid type of object (i don't logic).

player.cpp

#include "player.h" #include "messages.h" #include <iostream>  player::player(composite* parent) : entity(parent) {     createnode("../assets/sydney.md2");     //i = 0;     //v3f = vector3df(0,0,0);     /*networker = new networkcomponent();     addcomponent(networker);     networker->registervar(&i);     networker->registervar(&v3f);*/ }  void player::update() {     composite::update();     //std::cout<<i<<std::endl;     //std::cout<<"vectorx="<<v3f.x<<"\n"; }  void player::handlemessage(unsigned int message, void* data) {     switch(message) {         case damage: /* */;     }     delete data; }  player::~player() {     entity::~entity(); } 

i don't believe component-based design @ all. shouldn't entity deleted , composite , component used. shouldn't component base class empty , never used directly? component called 'rigidbody' holding data structure rigidbody data , functions overriding virtual component base class?

the posted code variant of composite pattern. design pattern structural pattern used allow clients treat individual objects , complex objects, such composed of multiple objects, in uniform manner. instance, rendering loop can iterate on collection of objects, calling draw() on each of them. structural pattern, difficult subjectively answer if instance of overengineering, require examining more class hierarchies , architecture.

however, neither class naming conventions of component , composite nor use of composite design pattern implies "component-based" design. not familiar game programming component pattern, appears strategy pattern state coupled within algorithm class, resulting in simplified interface between strategy , context. in either case, these 2 patterns behavioral patterns accomplish interchangeable , encapsulated algorithms. therefore, posted code not implement "component-based" design, neither component, composite, entity, nor player class provides means encapsulates algorithms in interchangeable manner. example, entity::update() calculate position in same manner. coupling requires entity class hierarchy expanded if entity needs use different physics model (consider case of entity warping planet different set of physics), rather delegating physics hierarchy of classes encapsulate algorithms.