我们目前的场景类Scene中不仅包含对场景节点的管理，还包含对场景中节点的绘制操作，也就是说当我们调用Scene::Update方法时：
scene->Update(time);
场景首先会遍历场景中的所有节点，更新场景中节点的位置信息，然后会找到场景中所有需要绘制的对象并执行渲染操作，伪代码如下：
void Scene::Update(float dt) {
UpdateTransform(dt);
RenderAll(dt);
}
void Scene::RenderAll(float dt) {
PreRender(dt);
vector<ModelPtr> models = GetModels();
for (int i = 0; i < models.size(); i++) {
ModelPtr model = models.at(i);
MeshPtr mesh = model->GetMesh();
VertexBufferPtr vertex_buffer = mesh->GetVertexBuffer();
IndexBufferPtr index_buffer = mesh->GetIndexBuffer();
MaterialPtr material->model->GetMaterial();
// Render model
// ......
}
PostRender(dt);
}
然而事实上，渲染作为渲染引擎中一个非常复杂的操作，将来由很大的变动空间。将管理场景和渲染场景这两项任务都写在一个类Scene类中，不符合单一职责原则。场景管理，包括节点位置信息以及相关状态的管理和更新和场景渲染是两个相对独立的功能。场景管理相对易于实现，功能也比较固定，场景渲染往往需要用到很多图形学技术，随着时间的推移，技术的进步，必然要不断的更新渲染模块。而当每次更新渲染模块式都需要修改并重新编译场景管理模块，无形中增加了维护和重构的困难。因此这里我们决定将场景管理和场景渲染模块解耦。这里简单介绍一下重构计划。
Component类表示节点的数据和行为。其中Model组件仅仅只是一个渲染数据的集合，只负责管理网格，材质等信息，不负责绘制，即移除Model::Render()方法，将渲染相关代码移动到Renderer中，让Renderer负责一切和渲染有关的操作，Component只负责维护数据。
Node类基本不变，Node::Update()只负责更新节点的位置信息等状态，不负责调用渲染函数。
Scene只负责场景管理，不负责场景渲染，Scene只是先场景的逻辑功能，渲染功能全部由Renderer实现。
新建Graphics类，将当前Renderer类的功能全部移动到Graphics中，Graphics类负责封装底层的图形API。Renderer类使用Graphics，负责实现场景的渲染逻辑。
Renderer类的实现参考Urho3d引擎的方法，在这里我们让Renderer包含一组Viewport，每个Viewport包含一个Scene对象，一个Camera对象，表示要绘制的场景和观察场景的摄像机，以及常见的(x, y, w, h)属性，用来表示窗口中的绘制区域。每次迭代将调用一次Renderer::Render()方法，该方法遍历所有的Viewport，读取Viewport中的Scene，Camera，查找Scene中的所有可渲染对象和灯光，并依次执行绘制。
这是就是本次重构计划。本次重构计划至少一周内完成。