why Ogre3D make you want to use it?

I do not know Ogre3D , and i had a comment in my last post regarding the analysis of Ogre3D.

I searched for the characteristics of this library and i found the following definition:

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.

And i decided to analyze it with CppDepend to discover its design advantages.

OGRE3D Architecture:

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 provide 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

SELECT TYPES WHERE IsDirectlyUsedBy "RenderSystem_GL"

its very useful to know which abstract classes are used by this plugin:

SELECT TYPES WHERE IsDirectlyUsedBy "RenderSystem_GL" AND IsAbstract

Which paradigme 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 inheritane increase complexity ,and we have to use it carefully.

Let’s search for class with many base classes.

SELECT TYPES FROM PROJECTS "OgreMain" WHERE NbBaseClass >1 AND ! DeriveFrom "Ogre.Singleton"

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 provide 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.

Lets 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 thoses 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 thoses 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 refactord, and i confess that i dont 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

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.

Lets 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 easly understand the utility of design patterns used, and its modularity can help you to accelerate the time of learning its capabilities.