DesignMisc：清晰的分层抽象

昨天review同事code的时候，发现一个case，就是在添加一个功能的时候，做了一个这样的操作：

• 在component功能性成员中实现一个功能，比如我们就简化为SetVisible，然后这样的操作了下：（当然实际情况要比这个复杂很多，方便blog这里简化下）

GraphicComponent* com = entity>GetComponent<GraphicComponent>();
Mesh* mesh = com->GetMesh();
mesh->SetVisible(false);

这里正确的写法是：

GraphicComponent* com = entity>GetComponent<GraphicComponent>();
com->SetVisible(false);

虽然代码的功能性是一致的，但是把component中的mesh拿出来的操作，则是一个复杂度提升一个level的行为。
我们人类单位时间里能够有效应付的复杂度是一个常量，提升一个模块的复杂度，就会导致我们开发效率和能hold住的规模的降低。
这样不是一个好的设计。

这个和团队中的分层管理结构非常的像，越级管理是部分情况有收益，总体上不可行且更低效。因为直接管辖低两级的同事，你没法对他进行一个全面的关注，这样做并不好。
所以原则上就是要有清晰的分层，每一级层级清晰，复杂度最简。