Strides Interactive

Object-Oriented for everything?Filed Under: Weekly Tuesday Dose of goodness

Dear all,

This week I’ll talk about some issues regarding Object Oriented Programming. This doesn’t apply to just C++ or Java, it’s the methodology itself.

There was once someone came and asked me why I didn’t make games with complete OO. I think the question was asked wrongly.

Find out why…

Introduction

First of all, we need to understand what’s the basic function of a methodology and its objectives.

There’s no silver bullet in everything we do; programming is of no exception.

In the past we used to write codes in a modular fashion, where function calls are part and parcel of programming. Then came Object Oriented Programming and took the development world by storm.

Why is it so? OO resolved a problem that modular programming has; that is the ability to categorize and generalize objects, creating them to resemble real-life objects.

In C, functions and variables are unique, they cannot be redeclared or redefined. Therefore, a strong naming convention must be in place to avoid hitting such problems which will lead to linker errors, ie (Symbol ABCDE(int, int) is already defined in XXXX.obj)

In C++, things changed. With classes, people can now instantiate objects and can have behavior (methods) that mutate the contents of the object.

Wonderful! But is that the end of it? No.

Limitations of Object-Oriented Programming

A typical limitation of OOP is that this methodology is meant to describe objects and not perform orchestration.

Yes, one might argue that a manager class can be written to perform the orchestration. This is technically true and correct, but it may not be feasible when time is tight.

Why?

Whatever we do in OOP are codes, and we know that codes have to be preprocessed, compiled, linked and integrated/deployed respectively (DLLs for example).

This process takes time. It’ll be stupid to even have to wait for 10 seconds just because a variable was changed.

In short, OOP is meant to describe objects. We can bend the rules to make it orchestrate but that’ll mean that coupling is high as well.

Common Pit-falls of OOP

When we go out and meet people who does OO, chances are they’re actually abusing the power of object-oriented programming.

One of which will be generalization.

The reasons behind it is simple:

- I inherit this parent class because I don’t want to do extra work.
- I want to work smart, do less but achieve more.
- I don’t want to duplicate codes
- Because I feel like it
- Because I can add objects into a collection

These are potential “reasons” that will lead to a disaster. Yes, a parent class can sometimes do the work for you. But remember, the more you inherit, the more tightly coupled the classes will be. Being tightly coupled disallows you to perform any changes without risking regression errors because so many classes go through the same path.

Therefore, inheritance should be avoided at all costs and be used only when it’s thoroughly justified. How can we justify inheritance?

If I cannot substitute my parent class, then I cannot inherit this class

To inherit a class, the potential parent class must be a class that can be substituted by your own class.
For example, a widget is inherited by various child classes such as:

<—– cEditBox
cWidget <—– cButton
<—– cTextBox

These inheritance actually mean something; it’s not just for the sake of inheriting from a common class. It’ll also be easier to visualize the possible regression impact since we’ll be familiar with widgets like edit boxes, buttons and text boxes if we should modify cWidget class.

Solution

As you’ve seen above, those are relationships between classes. They do not indicate a program flow, requirements flow or data flow in terms of business data.

They cannot perform certain tasks inherently.

An application orchestration language should be able to:

1) Process multiple data, multiple channels, concurrently
2) Handle time-related tasks such as wait, time elasped and so on
3) Perform all these in a synchronous and predictable fashion (which means threads are out)
4) Provide a logical flow of sequential actions which can be easily understood by the orchestrator
5) Avoid making the orchestration language look like a programming semantic-based language

Advanced abilities include:

1) Ability to launch multiple instances of methods or scripts and run concurrently
2) Ability to control flow of execution, immediate, batched or time-sliced
3) Ability to create scenarios that is readable and understandable by non-programmer

Once you’re in this area, the whole definition of development changes completely. Now, it’s about how to make things work hand in hand, rather than how to describe objects in a logical manner.

Timing and synchronization will be an impact aspect.

Conclusion

I’ve offered a theoretical solution yes? I know it’s just talk without any action. But in my next post, I’ll share with you the language that I’ve written that will perform the above-mentioned abilities.

So, watch out for my next post - SIGOL!

Thanks for your time!

Signing off,
Jeremy