I tend to think of DOD in a Component/Entity manner, where the Components are just pieces of Data, and an Entity is a collection of Components, and there are systems, which act on the components. So, the Brick would have a Location Component (Position and Velocity), a Color Component, a RectDimensions, and a Strength Component (how hard it is to smash), and it would be processed via the Brick System (for how to handle collisions). The ball entity would have the same components, except a Circle Component instead of Rectangle, and it would be processed by the Ball System, and the Paddle would have all those components, except it would be processed by the Paddle System. The paddle could have extra components as well, such a bullets, if it is able to shoot bullets (like Arkanoid did).

However, all these components are stored in like vectors, and are handled at the same time, but run through the different systems, based on which entity owns that component.

kind of like this (pseudo code):



class System {
virutal void HandleLocation(Location &locationComponent) = 0;
// fill with rest
};

class BrickSystem : public System
{
void HandleLocation(Location &locationComponent);
};

typedef uint32_t TEntity;

class Component {
TEntity Owner; // who owns us, unique value
System *ComponentSystem; // System to handle this component
};

class Location : public Component {
Vector2 Location;
Vector2 Velocity;
};

std::vector<Location> LocationList;
BrickSystem *BrickSys;

void main()
{

// Initialize the systems
BrickSys = new BrickSystem();

// Load the bricks
for (each brick to load) {
TEntity BrickEntity = GetUniqueId();
Location BrickLocation(BrickEntity, CurrentBrickX, CurrentBrickY, 0.0f, 0.0f);
BrickLocation.SetSystem(BrickSys);
LocationList.push_back(Location);
// Load other components into brick
}

}

void Update()
{
for (each it = item in LocationList) {
// Will call brick System handleLocaiton for brick's, BallSystem Handle Location for ball, etc
it->GetSystem()->HandleLocation(it);
}
}


Or something like that.