Class Structure

[BadgerFarmer]

Righto,

It's only this week had a little practical OOP click into place. Quite the revelation, really, I've been trying to hammer this stuff home for years (yes, since 2003) and it's only recently that the theory materialised on the screen in front of me.

So, having completed my first small project (a scrolling image viewer, out of interest) in what I believe to be reasonable style, I went on the hunt for a project with longer legs.

"Blobs" ("Balls" / "Circles" / whatever), are always popular, and seemed a reasonable place to start; though already I've exosed myself to the fact that the new knowledge hasn't clicked as loudly as it might have done. Try as I might, I just can't get my head around how to structure this simple project.

There's an example of a similar end product (for which I'm grateful), here...

Bouncing Balls (http://manewc.com/2008/01/24/as-3-bouncing-balls-with-collision-detection-within-bounds/)

... though from the perspective of OOP, this example looks (perhaps only to me) like it was only ever destined to be a quick example.

So, my terribly naive question is this:- Given the SWF above, how would you go about structuring the code beneath to make the project read more clearly, and more scalable?

Hopefully I'll start a discussion, hopefully...

[maskedMan]

The question is a bit big, and the answers may be contradictory.

Personally, I think the sample reads clearly enough. It might require a very light knowledge of physics to know that vx and vy are vectors, which could be solved by a more explicit naming convention, but other than that there's nothing terrible about it. Of course, longer variable names cause worse runtime performance, but on a small scale this is completely negligable... so in fact legibility works at cross-purposes against scalability in this case.


We could also pick on data types and algorithm choices (I'm not the one to talk to about the latter), but once again the scale of the application would have to be massive before it became an issue whether to use int or uint. Since placing code inside a function call is at best 1000x slower than simply executing the code where it stands, you'd want to cut out any extraneous function calls for the sake of performance, which allows you to scale the number of objects handled... but then this makes the scalability of the application code base a bigger problem. For performance, instead of delegating to 'detectAndMove(ball);' you would handle all the code from that function inside the enterFrame handler... but this is highly messy and difficult to extend. Of course, another big question would be "why use enter_frame at all here?" Why not have the enter_frame function called only by the document class, which then calls an update function on any relevant objects? While that isn't necessarily the fastest way to handle things, it doesn't take many ENTER_FRAME event listeners in your app to bog things down and you could be looking at more of those than you bargain for if you don't keep it in the document class... but does that aid readability? Are you ever likely to scale so large that this becomes a viable option? If you do, will it be enough?


In the end, the biggest hit to processor performance is graphics rendering. Figuring out a smart way to keep the display list clean, and not have anything exist on the list that isn't actually onstage will likely grant more performance gains than any amount of bit fiddling.


What's the takeaway here? There is no magic bullet. There are only a series of tradeoffs.