Lets search which classes are a singleton: To ensure a class has only one instance, the better way is to use the singleton pattern. Only a few classes are considered as no cohesive. SELECT TYPES WHERE LCOMHS > 0.95 AND NbFields > 10 AND NbMethods >10 AND !IsGlobal LCOMHS value higher than 1 should be considered alarming. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types. The LCOMHS (HS stands for Henderson-Sellers) takes its values in the range. A high LCOM value generally pinpoints a poorly cohesive class. The single responsibility principle states that a class should have more than one reason to change. Maybe it’s possible to do it differently to avoid this dependency cycle but it’s not a big issue. The namespace Ogre use all Cmd classes from the other namespaces, and all those classes are used by Ogre::ParticleEmitter as static fields, ParticleEmitter add them to CmdParam dictionary. SELECT TYPES WHERE IsDirectlyUsedBy “Ogre” Let’s search for the origin of dependency between Ogre and two other namespaces. SELECT TYPES FROM PROJECTS “OgreMain” WHERE IsAbstractĬppDepend provides DSM graph, and we can triangularize this matrix to focus on red borders highly dependency cycle.Ī dependency cycle exists between Ogre,Ogre::EmitterCommands and Ogre::OverlayElementCommands, having this dependency can be not problematic but avoiding this kind of dependency enforce loose coupling, this interesting post explain the benefit of layering.
Let’s search for abstract classes of OgreMain: Abstractnessįor a plugin oriented architecture, the host must have many abstract classes to be more flexible and extensible. Only a few classes derived from more than one class. Let’s search for the classes with many base classes. SELECT TYPES FROM PROJECTS “OgreMain” WHERE NbBaseClass >0īut multiple inheritances increase the complexity, and we have to use it carefully. Using object-oriented approach can imply an overuse of the inheritance to make the most of the polymorphism concept.Įspecially for OgreMain that represents the kernel of the Ogre3d framework, where many classes are designed to be overloaded by the plugin projects. The Ogre3D provides an interesting API to customize easily the rendering, which makes our task to adapt it to fulfill our needs very easy. The plugin can override the scenes, textures, rendering and more. SELECT TYPES WHERE IsDirectlyUsedBy “RenderSystem_GL” AND IsAbstract Let’s filter the below result and search only the abstract classes used by the RenderSystem_GL plugin: The plugin uses some utility classes, model entities and override some abstract classes to integrate the plugin into the Ogre3D ecosystem. SELECT TYPES WHERE IsDirectlyUsedBy “RenderSystem_GL” Let’s discover how the kernel project communicates with the plugins, for that let’s search which classes of OgreMain are used by the RenderSystem_GL plugin by executing this query: For that, the OgreMain project provides the needed classes to communicate with the plugins. The architecture is plugin oriented, it’s very useful to extend Ogre3D without any changes to the kernel project “OgreMain”.
The dependency graph shows the link between the OGRE3D projects: Let’s analyze it with CppDepend to discover its design advantages. The class library abstracts the details of using the underlying system libraries like Direct3D and OpenGL and provides an interface based on world objects and other high-level classes. OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible 3D rendering engine written in C++ designed to make it easier and intuitive for developers to produce applications utilizing hardware-accelerated 3D graphics.
0 kommentar(er)
