Object Oriented Programming and Flash pt.1

Logiblocks

Hey guys, Tom of The Super Flash Bros here, Dan has just given Dim and I permission to post here on the Armor Blog, which is awesome. If you don’t know us, we’ve been hanging around Newgrounds.com for about 6 years now, making movies and games, and working for Armor Games for over a year.

So, onto the topic of my first post -Object Oriented Programming, or OOP for short. Chances are, if you’ve been looking into programming for any length of time, you’ll have at least heard the term before. If you’re not already using it, then you’ll probably be using something akin to Procedural Programming (defining functions on the timeline and on MovieClips) or perhaps even Prototype-based Programming (adding functionality to Flash’s in-built classes with the prototype property). While it’s true that the best way to code is whatever way works for you, I’m going to show you some really neat uses of OOP and some very good reasons for using it.

So lets start off with some analogies. The center of OOP are the objects from its name. In Flash, the objects are instances of Classes. Classes can be thought of as templates for useful sets of data and processes that you then fill in with solid information when you create an instance of it. The classic analogy is Classes being the blueprints for something, and the instance being the finished product based on the blueprint. The analogy then expands to your whole programme, comparing it to the blueprints to an aeroplane, with individual blueprints to each part that makes up the whole. In particular, it points out that you have just one blueprint (class) for a plane seat, but you can have 100 chairs (instances) in your plane, knowing that every chair is going to act the same way based on the blueprint, but each instance differing by the information you give it, in this case the position in the plane.

Now while that’s a useful analogy in explaining the very basics, I really like this next one that explains why you’d use OOP. Do you remember those simple electronics kits you get as a kid? The ones with different components in little plastic blocks that you clip together in different ways to make different circuits. Here’s an example: http://www.logiblocs.com/index.htm

In these sets, every block has a well defined input, function and output, some with a secondary input or interface. You know that if you connect the light block to your circuit and you input some current, it will output some light. The important thing here is that you don’t need to know anything at all about how that light block works on the inside, only that it will work as you expect. That means that you can use it in any circuit that needs a light without having to change anything about the light block itself.

I hope you can see my point here. The light block is a Class that you or someone else has written (MovieClips, Buttons and Arrays are all Classes that someone else wrote) and the circuit is your programme. If you’ve written your class properly, you can re-use it again and again in any programme you write in the future, in the same way you use MovieClip in just about every flash programme ever, because you know what it does without having to think about how it does it.

That’s one of the core ideas of OOP: Encapsulation – the idea that you can hide the internal workings of an object (instance of a class) to make it simple to use in your programme and re-usable in future programmes.

Tomorrow I’ll be covering basic Class structure and inheritance. See you then!

Tom-