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 utilising hardware-accelerated 3D graphics. 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.
Let's analyze it with CppDepend to discover its design advantages.
The dependency graph shows the link between OGRE3D projects:
As we can observe the architecture is based on plugin concept, its very useful to extend Ogre3D without any changes to the kernel project OgreMain. For that OgreMain provides classes to use for a plugin, for example we can see which classes of OgreMain are used by RenderSystem_GL plugin. To do that we can execute the following CQL request:
it's very useful to know which abstract classes are used by this plugin:
Let's search for global functions to discover if Ogre3d is Procedural oriented?
How about generic paradigm:
Only few classes are templated so Ogre3d is mostly object oriented.
Using object oriented approach can implies an overuse of inheritance to exploit polymorphism concept.
Specially for OgreMain that represent the kernel of Ogre3d framework, where many classes are designed to be overloaded by plugin projects.
But multiple inheritance increase complexity, and we have to use it carefully. Let’s search for class with many base classes.
Only few classes derived from more than one class.
For a plugin oriented architecture, the host must have many abstract classes to be more flexible and extensible.
Let's search for abstract classes of OgreMain:
CppDepend provides DSM graph, and we can triangularize this matrix to focus under red borders highly dependency cycle.
A dependency cycle exist 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 the origin of dependency between Ogre and two other namespaces.
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.
Maybe its possible to do it differently to avoid this dependency cycle but its not very problematic.
The single responsibility principle states that a class should have more than one reason to change. Such a class is said to be cohesive. A high LCOM value generally pinpoints a poorly cohesive class. There are several LCOM metrics. The LCOM takes its values in the range [0-1]. The LCOMHS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types. LCOMHS value higher than 1 should be considered alarming.
only few classes are considered as no cohesive.
To ensure a class has only one instance, the better way is to use singleton pattern.
Lets search which classes are singleton:
SELECT TYPES WHERE DeriveFrom "Ogre.Singleton"
As we can observe almost all manager classes are singleton, in general a manager is a good candidate to be singleton. And we can search for manager classes that not derived from Singleton
Only few managers are not derived from Singleton, it's normal because those classes can be instantiated many times.
The factory pattern is very useful to abstract the creation of objects,it enforce low couplig and high cohesion as explained in this post.
but having factory not implies that an instance is created by this factory, because we can instantiate the class directly, and we have to define a rule to be sure that the factory is used for instantiation.
For example about Entity class we can define the following rule to discover each class instantiate it:
As we can observe only EntityFactory instantiate the Entity class.
Manager classe give access to a subsystem, is very useful to modularise the project, and Ogre3d contains many managers, each one represent a different subsystem.
SELECT TYPES WHERE NameLike "Manager$"
Facade defines a higher-level interface that makes the subsystem easier to use, and we can detect facade for your project by using Efferent Coupling metric. The Efferent Coupling for a particular type is the number of types it directly depends on. Types where TypeCe > 50 are types that depends on too many other types. They are complex and have more than one responsability. They are good candidate for refactoring.
But sometimes in the case of facade, having a high TypeCe can be normal.
Lets search for classes with high TypeCe:
Not all of those classes are facade and for each class of them we can maybe find an explanation why TypeCe is high, and maybe some classes can be refactored, and we confess that we don't master Ogre3d to explain that.
And the facade mostly used is Root class, let's see what subsystem this class use.
As we can observe Root class use almost all manager classes.
And we can search for manager not accessible by Root by this following CQL query:
SELECT TYPES WHERE !IsDirectlyUsedBy "Ogre.Root" AND NameLike "Manager$" AND !IsAbstract
The observer is a pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement event handling systems.
Ogre3d use Listener classes to implement the observer pattern.
Let's search for Listener classes for OgreMain project.
Ogre3d is very clean as library, very well designed and very well commented.You can easily understand the utility of design patterns used, and its modularity can help you to accelerate the time of learning its capabilities.
2009 - 2024 © All Rights Reserved. CoderGears / CppDepend
