Modular Object Orientation Explained

The concept of object orientation was first introduced in 1967 when it was first implemented in a language known as Simula. Although this was followed by the more well-known Smalltalk, it was not until 1985 that object orientation concepts started to increase in popularity with the advent of C++. Historically we know that object orientation implementations have been focussed on languages, and this trend continues today with modern languages such as Delphi, Visual Basic, Java and many others. For the most part, this has been an improvement over the classic procedural languages such as C, Pascal and BASIC, but there are issues at hand that prevent all potential benefits of object oriented methodology from being realised through language implementation.

A key problem with this approach is that object oriented languages will compile down to procedural programs, simply because they target procedural systems. Such programs are also limited in that their "object oriented world" is limited to their own locale, resulting in one methodology being used internally, and the methodology of the target system being used externally. The more object oriented programs that a user runs, the more object worlds are created on the one machine. Not being able to integrate the worlds into one cohesive structure is a significant limitation, and you will understand why this is the case by the time you reach the end of this document.

A number of myths have also surfaced over the years regarding the benefits of object oriented languages over their procedural counterparts, in order to promote the use of OOP languages. Let's examine a few of these claims:

"An object oriented language is required to create object oriented programs."

C++, Java, Delphi and the majority of other languages are in fact, object oriented tools that produce procedural programs. Because the resulting applications live within their own private object space, it can be argued that while the 'input' is object oriented, the output is not. In a modular environment such as that provided by Pandora you can actually create object oriented programs using C, DML, Assembler or any other language of your choice, with an end result that exhibits more advanced object orientation than what existing object oriented languages can produce.

"Using object oriented languages creates more reusable code."

This claim is commonly used by software companies that want you to buy into their product so that you can save money in the long term. There is no valid reason why C++ classes are any more reusable than well-documented C based functions. In fact, many object oriented languages are heavily disadvantaged in the area of re-use, as each language uses different protocols for object construction - try sharing an object created in C++ with applications written in Java, Delphi and Visual Basic. Not so reusable now, is it?

This brings us back to a similar problem that we discussed earlier, that of each program creating their own object worlds that are effectively cut-off from the rest of the system. Once again, a modular approach will solve the issue, as both system and program code will conform to the same standards.

"Modern object oriented languages have improved resource management by providing garbage collection services."

Garbage collection slows the program with algorithms that assess what resources are no longer in use. Work as it may, it is also inefficient, and resourcing issues that are lingering in the program will never be brought to your attention (if you don't know that resource management errors exist in your program, it can be difficult to fix them). Garbage collection and other "silent" resource tracking methods often encourage lazy programming habits.

A cleaner and more efficient method is for the system to handle resource tracking for each individual object that is created, not for the language to do so. In Pandora's case, the object kernel not only guarantees that it knows where every resource is in the system, but also what objects own what resources. It also guarantees that the moment any object is terminated, all of its resources will be destroyed and if necessary, errors will be printed to indicate where problems may lie.

The issues that we have raised exist because object oriented languages have evolved only so far as to provide a stop-gap implementation of object orientation on procedural systems. We have no issues with the actual concept of object oriented languages, but without an end-to-end solution, it's much like building a house without roofing or a foundation. In summary, while the theory behind object orientation is no way in dispute, it can only ever be as good as the method of implementation that has been used. This leads us to the development of modular object orientation - it's the same concept, but the implementation is a system-wide design that allows both developers and users experience the full benefit of object oriented theory.

History

The Modular Object Orientation design model was originally conceived through what might be called "accidental evolution" during the year of 1997. This may be an unusual beginning for a project of its size, but the concept grew out of a need for writing system code that was object oriented in nature, without being restricted to an object oriented language. At the heart of the system was an object kernel, a hybrid of traditional kernel code and API functionality mixed with object oriented principles. From that came the development of modules, API's that could offer traditional function-based services, but also class-based services from which objects could be created. After years of development the Pandora Engine evolved to offer a whole host of operating system services, which eventually led to the development of Athene, the friendly face that was created so that users could enjoy the benefits of a modular object oriented system. At approximately the same time DML was created as the first language designed to take full advantage of the MOO structure provided by the Pandora Engine.

At the time of writing this document, the Pandora Engine is available for Linux and Microsoft Windows systems, with more to follow. While the short term goal is to ensure that the system is available on most popular platforms, the focus in long term goals will shift according to where third party developers, such as yourself, choose to put the Pandora Engine to use. You are as much of an important part of the project's development as we are, so if you want to have a part in the product's future, don't hesitate to let us know your thoughts as to what you want to see over the next few years of the Pandora Engine's development.

Feature Overview

The MOO design model featured in Pandora supports all of the standard features expected of a modern OO implementation. Classes, objects, polymorphism, inheritance and methods are all supported. A number of other features are provided on top of this, some of which we will briefly touch on in this section. They are:

Action Support

Actions provide a way of making function calls in a way that is more similar to real-world semantics. Although it is possible to invoke calls on an object via methods, actions differ in that they are generic functions that can be 'applied' to objects. For instance, if you want to move an object on the display then you simply apply the Move action. A full list of available actions is provided in the Action Document.

Sharing and Communication

Objects can be declared as private, shared or public. When you share an object, other programs can interact with it in conjunction with your program. Public objects are a special type of object that can be created outside of your program space, allowing them to stay in the system even when your program is terminated. Object networking is also supported so that objects can be shared, distributed and interacted with over networks.

Supportive Inheritance

Class inheritance can be used to add support for foreign data files and special features to any existing class. For instance, a Jpeg sub-class adds support for jpeg files to the Picture class (which by default only supports IFF files).

Polymorphism and Abstraction

Polymorphism is supported in the system through the action services, as well as polymorphic field operations. We tend to refer to polymorphism as abstraction.

Dynamic Resource Tracking

Resource tracking is provided at the object level. Resources allocated by an object will always track right back to that object - not the task that owns it. This feature is a vital requirement for modular OO, and really comes into its own for extremely large programs that need efficient resource management. Interestingly, an object does not have to belong to any programs in order to exist in the system, but all objects take part in the structure of the system's object hierarchy as part of the resource tracking process.

Architectural Breakdown

At the heart of the Pandora Engine lies the object kernel. This provides an object management service that is responsible for creating, maintaining and destroying objects in the system. By ensuring that every object originates from the same centralised system, standards can be developed that allow the programs and objects in the system to talk to each other through a common interface. Once a global standard has been established, the level of communication in the system goes up ten-fold simply because every program is speaking the same protocol.

With an established means of object oriented control, it becomes important to look at how classes will be added and managed within the system. This is where the term "module" comes into the picture. Rather than creating classes in a compiled program, Pandora classes are defined in their own module files, and are loaded on demand. Module code is shared in memory, which means that each object that is created exists as a new instance of data, but the code is not reloaded. This means that the memory usage of Pandora is extremely light, and reduces the impact on memory usage for new objects to a few hundred bytes of data.

One of the issues that is not often addressed when creating object based server models is that each object tends to sit alone in memory with no relationship to other objects in the system. This in itself is not a problem, but it prevents objects from forming a cohesive, manageable structure. Think of it in terms of building a house out of bricks - in order to build a cohesive structure each brick needs to be cemented together. The cement acts as glue that holds the bricks in place and effectively forces them into a massive hierarchy of objects. In this case, what we've actually done is to use brick objects to create an entirely new type of object - a wall. This is a rather simple example, but it illustrates that by using relatively simple objects like bricks, wood, nails and wiring, we can create an extremely complex object like a house. The power of hierarchy and structure is not to be underestimated, and Pandora takes this to the ultimate level by requiring all objects to take part in the system hierarchy. With a hierarchical foundation, we can then achieve new concepts such as object based resource tracking and allow more effective searching of the object tree. If you've used Athene and DML before, you may already know that complex objects like windows and menus can be easily created from many simple objects like boxes, lines and text. This illustrates the basic premise of Modular OO - to achieve complexity only through the use of simplicity and structure.

The following diagram illustrates some of the default modules and classes defined by Pandora and Athene:

Pandora Design Model


At the head of the system lies the object kernel. Besides the functions provided by the kernel, a number of internal classes are also defined that are necessary to get the system up and running. Hardware modules take the next level of precedence, representing an abstraction layer of the underlying system. Although hardware modules will communicate with lower-level devices almost exclusively, it is also possible to write new modules that access hardware directly if required. This will always create faster code, but at a cost of development time if the driver is already available in the underlying system.

The software modules and classes are responsible for defining the range of services available within the Pandora Engine. Software modules are highly portable and their communication extends back to the object kernel, hardware modules and each other. Sub-classes are also prevalent in this area, for example the Picture class has PCX and GIF sub-classes hooked into it in order to support extra file types.

The lower layer illustrates the use of components, which are basically classes that provide GUI services. They are responsible for user interaction and their ability to communicate with each other is paramount. Components are also used in scripts to build the GUI interface, and as such represent the face of the operating system that is built at run-time. The beauty of components is that they can be added and deleted according to what is required by the user. System growth is highest in this area, and new components are very easy to build and maintain. The majority of components produced by Rocklyte Systems are distributed as part of the Athene package, as the Pandora Engine distribution is focussed on providing low to mid-level development support in its archive.

Next: Installation Overview


Copyright (c) 2000-2002 Rocklyte Systems. All rights reserved. Contact us at feedback@rocklyte.com