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 analyze it with CppDepend to discover its design advantages.
OGRE3D Architecture
The following dependency graph shows the dependencies between the OGRE3D projects:
As we can observe the architecture is based on the plugin concept, its very useful to extend Ogre3D without any changes to the kernel project OgreMain which provides needed classes to use for a plugin, for example we can see which classes of OgreMain are used by RenderSystem_GL plugin. For that we can execute the following CQLinq request:
SELECT TYPES WHERE IsDirectlyUsedBy “RenderSystem_GL”
For a plugin it’s also very useful to know which abstract classes are used by it, it give us an idea about the contracts implemented or used by the plugin.
SELECT TYPES WHERE IsDirectlyUsedBy “RenderSystem_GL” AND IsAbstract
Which paradigm is mostly used?
Lets search for global functions to discover if Ogre3d is Procedural oriented?
SELECT METHODS FROM PROJECTS “OgreMain” WHERE IsGlobal AND !NameLike “^operator”
How about generic paradigm:
SELECT TYPES WHERE IsTemplate
Only few classes are templated so Ogre3d is mostly object oriented.
Inheritance
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.
SELECT TYPES FROM PROJECTS “OgreMain” WHERE NbBaseClass >0
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.
Abstractness
For a plugin oriented architecture, the host must have many abstract classes to be more flexible and extensible.
Lets search for abstract classes of OgreMain:
SELECT TYPES FROM PROJECTS “OgreMain” WHERE IsAbstract
Namespaces layering
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.
SELECT TYPES WHERE IsDirectlyUsedBy “Ogre”
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.
Type cohesion
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.
SELECT TYPES WHERE LCOMHS > 0.95 AND NbFields > 10 AND NbMethods >10 AND !IsGlobal
Only few classes are considered as no cohesive.
Design patterns used
Singleton
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 that 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
SELECT TYPES WHERE !DeriveFrom “Ogre.Singleton” AND NameLike “Manager$”
Only few managers not derived from Singleton, its normal because those classes can be instantiated many times.
Factory
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:
SELECT METHODS WHERE DepthOfCreateA “Ogre.Entity” == 1
As we can observe only EntityFactory instantiate the Entity class.
Manager
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
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:
SELECT TYPES ORDER BY TypeCe DESC
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 i confess that i 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 CQLinq query:
SELECT TYPES WHERE !IsDirectlyUsedBy “Ogre.Root” AND NameLike “Manager$” AND !IsAbstract
Observer
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.
SELECT TYPES FROM PROJECTS “OgreMain” WHERE NameLike “Listener$”
Conclusion
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.