flipCode - Tech File - Jeroen Bouwens [an error occurred while processing this directive]
Jeroen Bouwens
Click the name for some bio info

E-Mail: flipcode@jeroen.ws


   08/14/1999, Object Design


Right, another day, another tech-file update. Unfortunately, work on my 3D engine Manic Motion has been very low-profile since my last update. Reason for this is my transition from being a student to being an employee. I now have a job as software engineer at Philips Electron Optics.

The good news is that in a very short time, I have learnt quite a lot about a number of subjects I wasn’t exactly good at in the past. One of these things is object design, and I would like to share some thoughts on this subject with you. Maybe a lot of this is old-hat for some or even most people out there, but I’m going to write it down anyway. It’s general programming stuff, so no fancy 3D algorithms. The reason to put it in my tech-file and not in the tutorials file is that I’m on a rather steep learning-curve at the moment, and it’s quite possible the views I present here will change in the near future. But I wanted to write something about it anyway, because writing forces me to think clearly. A tech-file is probably a better place to make mistakes than a tutorial .

In my last update, I said that I consider good object-design to be very important. This was wrong. At my new job, some 30 people are working on a project consisting of several hundreds of code modules, and thousands (!) of objects. Good object design is not just very important here, it is absolutely vital to produce functioning software. And out of these 30 people, there’s a group of 3 working full-time on architecture and design. This indicates how important architecture and design are according to management.

First of all, there is a difference between Object Oriented Programming (OOP) and an Object Oriented Language (OOL). C++ is an OOL. It provides the tools and the framework in which you, the programmer, may or may not choose to work Object Oriented. OOP on the other hand is a general way of thinking which enables us, humble mortals, to design,manage and gain insight in complex systems.

One of the most important lessons I have learnt in the past few weeks is why to use OOP in the first place. My personal answer at the moment is: Because it allows you to write code which is derived from a high-level design.


A high level design is something like this (Don’t take it too seriously please):

This diagram is very superficial and simple, yet it already provides information on the class-structure which will eventually emerge for this game-engine. You can see the complete engine consists of a number of sub-engines, each with their own, well-defined task. Now, as you all know, a 3D engine can also be sub-divided into even smaller blocks. This subdividing into ever smaller blocks is iterative, and the final logical step is the transition to an actual class-structure. That is the power of OOP: You can think about and work on a design in abstract concepts, plot relations, assign responsibilities, and finally make an easy translation to the actual implementation in an OOL. This is very different from traditional programming, where there was a huge gap to cross between the logical/ structural design and the actual implementation.

OOP is built on a few concepts. In my view the first and foremost concept is Encapsulation. Encapsulation may be the most important concept in OOP, yet to explain it in words can be difficult. One way of explaining encapsulation is that an object only does the things which are its responsibility. For example: When you write a 3D engine, you’d have an object responsible for rendering and a separate object responsible for actually blitting the rendered scene to the screen. Ideally, this means you can port your engine to other platforms by simply adapting/rewriting the blitting object, while the rendering object remains unchanged. A wel encapsulated object resembles a black-box: You put something in, and something else comes out, but how it works internally is completely unclear. Also, you are completely unable to reach inside and change the behaviour of the black-box. An example: 

Class A
{
    public:
        int q;
}

Class B
{
    public:
        A Member;
        void Method();
}

void B::Method()
{
    Member.q = 10;
}
This is bad encapsulation. Class B is messing around with a member-variable which Class A should never have made public in the first place. The encapsulated way would be: 

Class A
{
    private:
        int q;
    public:
        void SetQ(int value);
}

Class B
{
    public:
        A Member;
        void Method();
}

void A::SetQ(int value)
{
  q = value;
}

void B::Method()
{
    Member.SetQ(10);
}
This is encapsulation in its simplest form. In practice, it means that the member variables of a class are only accessible through methods. In other words, instead of simply changing the value of an objects’ member, you ask nicely if the object would be so kind to change the value for you. Do this on all class-levels, for everything, and you’ve come a long way to a tidy design. You’ll see that by trying to achieve encapsulation, which is important for reuability, you’re forced to think about which class should perform which task.

Well, this text is getting quite lengthy already, so I’ll just stop here. If you find this interesting, please let me know, and I might write some more on the subject. But bear in mind I am by no means an expert on OOP.

Happy coding,
      Jeroen





  • 04/01/2002 - Thoughts On Software Development
  • 09/10/2000 - Observe Your Objects
  • 01/31/2000 - Factories
  • 09/14/1999 - Polymorphism and Inheritance
  • 08/14/1999 - Object Design
  • 06/04/1999 - OpenGL Mania
  • 05/04/1999 - 3D Clipping
  • 04/29/1999 - Introduction
    • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    Download The Sample Program: ManicMotion.exe

    [an error occurred while processing this directive]