As3: Object Oriented Programming

[Diki]

AS3: Object Oriented Programming
----------------------
AS3: Main
----------------------

What is this tutorial going to teach me?
The theory behind OOP using practical examples and analogies.
I will not be dumping pages of code at you to show you what OOP looks like. I am just going to explain what OOP is and how to write it.

What is "object oriented programming"?
Object Oriented Programming, or OOP for short, is a programming paradigm where you treat your data as "objects". It is in stark contrast to procedural programming, which is a different paradigm.

Is OOP the best choice?
Yes and no. OOP is not a blanket paradigm that will solve any issue that you throw at it. It is good at some things, and bad at others.
However, because of the nature of AS3, it would be difficult to be in a situation where OOP is not the ideal choice.

But this is worth stating, so I will: Object Oriented Programming is not "better" than procedural programming or any other paradigms.
That is like saying that multiplication is "better" than division because it is computationally less expensive. Division may require more resources but it is just better suited for certain tasks than multiplication is.

How do I start writing OOP?
This is a difficult question to answer. It is possible that you have been writing OOP without ever knowing it, albeit that is unlikely.
As well, if you are accustomed to writing procedurally then learning OOP might be tricky.

Having said that, if you want to start writing your code in the OOP paradigm, then you just need to start thinking of your code as objects.
Take this code for example:

var player:Sprite = new Sprite;
var health:int = 100;

Intrisically there is nothing wrong with that; creates a player, and a health value for said player.
But this is using the procedural paradigm when OOP should be used instead:

var player:Player = new Player({health:100});

A class unique to the player has been created. The constructor takes an Object type that can define the player's health.
The health value would then be stored in a private member variable in the Player class.

Isn't that simpler?

The Player class would also extend another class, which would be called something like Character or LivingObject; something that will make it clear that the class is for a character in the game.
More on this in the following sections.

How to Design an Application Using OOP
Knowing how to properly utilise OOP while designing your applications is imperative.
The best analogy that I can make is the taxonomic rank biological classification for life.
The taxonomic rank can be represented as the following, ignoring domain:

Kingdom
Phylum
Class
Order
Family
Genus
Species

The kingdom describes the most broad amount of life. Examples being anamalia, plantae and fungae.
The class is a little further down the ranks, and as such it describes a lesser amount of life; it is more specific. Assuming that the kingdom is anamalia, examples of class would be: aves, mammalia or reptilia.
Finally, the species is as far down the ranks as you can get; it is the most specific of the classiciations. Assuming that the kingdom is anamalia, and the class is mammalia, a perfect example of a species would be: homo sapiens. In other words: human beings.

So how does this all apply to programming?

Think of each rank as a class that you coded. Each subsequent rank extends the ones above it.
So, for example, if you were to pretend that human beings are a class you could look at the hierchy like this:

class HomoSapien extends Homo extends Hominidae extends Primates extends Mammalia extends Chordata extends Anamalia

HomoSapien would be the class that is "most specific", working its way up to the "least specific" class Anamalia.

So how abstract should I make my classes?
Ideally you want to make your classes as abstract as possible. Just as you should try to write functions that only do one thing, you should try to write classes that represent as little as possible.
More classes that individually represent less is far better than less classes than individually represent more.

Of course, take this with a grain of salt. I am not at all advocating that you create classes like this:

class XPosition
{
	private var __mValue:Number;
	
	public function XPosition(value:Number):void
	{
		__mValue = value;
	}
	
	public function getValue():Number
	{
		return __mValue;
	}
}

That would be retarded, and incredibly redundant.

Summary
I feel that a gross over-generalisation is necessary here:
- Write abstract classes.
- Write re-usable code.
- Combine the two and you'll have object oriented programming.

Because, really, that's about all there is to it.
If you need a class to store an enemy in you should first create a class to store game characters in, and before that, you should create a class to store game objects in.
Treat your class hierchy as the taxonomical ranks and you will be fine.

And remember: like all things, OOP will come with practice. Don't expect to "get it" immediately.

[Sandremss128]

OOP is also about encapsulation, which means classes communicate through well defined API's. Using:

var player:Player = new Player({health:100});

as an example for OOP is a bad one because sure you are passing an 'object' as parameter but its not typed. Better would be to use an integer typed argument for health, or a defined object that is guaranteed to have the properties needed for initialization for this object. For all we know we could be putting an empty object in there..
The most important concept of OOP is that every class is a self confined unit, a unit responsible for only its internal data and operations; yet capable of communicating with other classes through a well defined interface.
Better would be:

var player:Player = new Player(new InitObject(100));

Sure you could make the constructor function of the Player class check for the health property and throw an error if its not there.. but resolving problems before they can arrise through proper OOP is better.
I think there needs to be more emphasis on the Object itself and how important encapsulation and self confinement is, besides that its a nice tutorial.

[Diki]

At 12 minutes ago, Sandremss128 wrote: OOP is also about encapsulation, which means classes communicate through well defined API's. Using:

var player:Player = new Player({health:100});

as an example for OOP is a bad one

I will admit that that is not an ideal example of OOP, but it's how I teach/write tutorials.
The specifics of what makes that example inadequate are not relevant to the context of the example, so I just threw a simple Object declaration. I always try to avoid giving too much information at once in my examples lest they not be as well understood.

Basically: that example was only concerned with having a Player class. Not how the Player class should be implemented.

At 12 minutes ago, Sandremss128 wrote: because sure you are passing an 'object' as parameter but its not typed. Better would be to use an integer typed argument for health, or a defined object that is guaranteed to have the properties needed for initialization for this object.

I briefly touched on that in my post: "The health value would then be stored in a private member variable in the Player class.".

At 12 minutes ago, Sandremss128 wrote: Sure you could make the constructor function of the Player class check for the health property and throw an error if its not there.. but resolving problems before they can arrise through proper OOP is better.
I think there needs to be more emphasis on the Object itself and how important encapsulation and self confinement is

It's pretty difficult to write a brief tutorial on a BBS that will explain object oriented programming in its entirety. You could write an entire book on the subject.
Though, admittedly, it slipped my mind to include encapsulation in the tutorial. Oh well. :)

Who knows, I might write a second part to this tutorial to include other aspects of OOP.