[AS2] Thinking process - From procedural to OOP style scripting

programming flash
1

Hi everyone,

I posted a thread on tutorials regarding making a full OOP site a couple of days ago

Now I’m stuck on how to breakdown a given functionality into resuable classes. I’ve taken a past component I’ve scripted a few months back (in procedural way of coding) and try to recode it to help me have a better understanding on how classes in conjunction to interface instances.

FLA
Click to see what the component does

The style of scripting is very messy and lots of repetitive codes, as most of the time I just jump straight into scripting without prior planning (bad habit) :m:
Now with this component as a base, I want to learn how to manage my codes in a cleaner, more efficient way, OOP style. (I only get to know about how good and time-efficient OOP style programming is after I ‘discovered’ the Tween class a month ago lolx)

For a start I will need some planning… that’s the place where I’m now stuck in…
I’ve come out with the core items which I think should be as classes

  1. Controller
  2. Drag clips
  3. Hit boxes

How much further should I break them down? Read from tutorials that generally classes should only perform one task is that true? The controller deals with 2 tasks (handling events and ‘calculation part’), should I break them into 2 separate classes?

From tutorials I also get to know that we can assign a class to a symbol in the library. Is it possible for to attach classes at runtime to script generated or existing timeline instances? something like instanceName = new classFunction(parameters) ?

I’m new to OOP, any advice will be greatly appreciated. :angel:

(P.S For those who which to use the component which I’ve posted, it’s available to use in any way for free. Just drop me an email.)

2

Well actionscript 2.0 's object orientedness is what separates it from rest of the languages known to us today…

Animation with order is what it is… :slight_smile:

spend time with it… rather i will suggest

  1. start with prototype style oops in actionscript 1.0

  2. get some good ebooks on oops + actionscript (message me if you need)

  3. build very small applications with small codes to get you started…

then one day you will be there :slight_smile:

3

Planning is the one task that will make OOP go easier, and is the main single thing that will allow OOP to really work vs. just being a pain without a goal in sight - ie, you want to build reusable, clean, efficient code. So, you’re on the right track. I agree with the previous post in getting your hands on numerous flash OOP books. I wouldn’t try to tackle design patterns just yet (though pick up some books on OOP and design patterns too) - patterns are whole 'nother system that might be confusing.

I like having many many books on OOP - there are many different opinions and techniques… and getting a glimpse of all of them will allow you to find items that make sense and apply to your applications at hand.

Also, if sticking to AS2 OOP for now, get a good handle on the EventDispatcher class and how you can use that within your classes to allow communication. This will better prep you for AS3 OOP.

You’re thinking on your drag/drop structure is heading down the right path - always think about which objects contain enough functionality that they just might require their own class. Also, always thing ahead - you’ll probably want your app to be able to accept two up to fifty draggable items… will they always be the same size? will they always only snap to one target, or can they have the ability to snap to several targets? Are the targets always going to be in that one container area, or can you distribute them else where? Things like that will affect how your app should be structured.

At a very quick glance, these objects would all have their own classes…

ModelClass - class that stores data (maybe how many draggables, how many targets, the relationship of draggable-to-target etc.)

MainManager class - equivalent to the Document class in as3 - this is the starting point for your app, it instantiates items and allows them to be built (doesn’t have to be a class, maybe its timeline code that gets things going - but its nice to know where this is at and that its isolated in some fashion)

DraggableObjectClass

TargetObjectClass

Controller - controllers are difficult (imo) in the beginning. I think a lot of people start by separating the model first (in this case all the data that defines how the app gets set up) - Then the view classes and controller classes are kinda one-in-the-same.

Hope this helps

4

[quote=sparkdemon;2332550]Well actionscript 2.0 's object orientedness is what separates it from rest of the languages known to us today…

Animation with order is what it is… :slight_smile:

spend time with it… rather i will suggest

  1. start with prototype style oops in actionscript 1.0

  2. get some good ebooks on oops + actionscript (message me if you need)

  3. build very small applications with small codes to get you started…

then one day you will be there :)[/quote]

Thanks for the feedback. Any recommendations for good OOP books?

5

[quote=creatify;2332687]Planning is the one task that will make OOP go easier, and is the main single thing that will allow OOP to really work vs. just being a pain without a goal in sight - ie, you want to build reusable, clean, efficient code. So, you’re on the right track. I agree with the previous post in getting your hands on numerous flash OOP books. I wouldn’t try to tackle design patterns just yet (though pick up some books on OOP and design patterns too) - patterns are whole 'nother system that might be confusing.

I like having many many books on OOP - there are many different opinions and techniques… and getting a glimpse of all of them will allow you to find items that make sense and apply to your applications at hand.

Also, if sticking to AS2 OOP for now, get a good handle on the EventDispatcher class and how you can use that within your classes to allow communication. This will better prep you for AS3 OOP.

You’re thinking on your drag/drop structure is heading down the right path - always think about which objects contain enough functionality that they just might require their own class. Also, always thing ahead - you’ll probably want your app to be able to accept two up to fifty draggable items… will they always be the same size? will they always only snap to one target, or can they have the ability to snap to several targets? Are the targets always going to be in that one container area, or can you distribute them else where? Things like that will affect how your app should be structured.

At a very quick glance, these objects would all have their own classes…

ModelClass - class that stores data (maybe how many draggables, how many targets, the relationship of draggable-to-target etc.)

MainManager class - equivalent to the Document class in as3 - this is the starting point for your app, it instantiates items and allows them to be built (doesn’t have to be a class, maybe its timeline code that gets things going - but its nice to know where this is at and that its isolated in some fashion)

DraggableObjectClass

TargetObjectClass

Controller - controllers are difficult (imo) in the beginning. I think a lot of people start by separating the model first (in this case all the data that defines how the app gets set up) - Then the view classes and controller classes are kinda one-in-the-same.

Hope this helps[/quote]

Thank you, these are great information. :angel:
Hmm what’s the difference between Model and Controller classes? (one just holds the data and the other executes them?)

If I’m to make a DraggableObjectClass I can ‘attach’ it to any sprite/movieclip to make it draggable? Or do I need to extend the class for each individual item (there might be cases where the draggables are different)

6

[quote=Rin;2332762]Thank you, these are great information. :angel:
Hmm what’s the difference between Model and Controller classes? (one just holds the data and the other executes them?)[/quote]

This has to do with design patterns - it difficult to explain. The model is a class that contains, in general, set up data and other constants that can be accessed by any other portion of the site. The idea is, the model can change, but the View (other classes) don’t need to know about it - they just react and “work” based on the settings with the model. The controller is the guts of the application - however doesn’t necessarily deal with the View - the things you see and interact with.

You can create a class, and instantiate it by passing reference to the manually created draggable movieclips - something like:

var newdragger:DraggableObject = new DraggableObject(youClipName);

Or probably more preferable: your DraggableObject class extends the MovieClip Object - and its set via the linkage settings to a clip in your library. Then to create new DraggableObjects, you simply use attachMovie to attach instances of that object - you then pass the object parameters to uniquely set each object.

7

One of the best books ever