Where do YOU put your classes?

[Groady]

I've been trying to tidy up some of my own custom classes lately and am trying to decide on the best way to structure my classes.

I'm wondering how YOU structure your packages when working on a project. I find there are certain classes I use regularly (like a custom Math class) and others which are created specifically for the current project (like custom DisplayObject's etc).

I'm trying to figure out if it's best to keep all classes within a master root package OR is it better to separate re-useable classes from project specific classes? I can see a benefit of manually copying classes to a local project structure for backup purposes. Having a global library could cause problems if a method gets renamed and a old project needs re-compiling.

What do you think?

[yell0wdart]

I generally create packages for specific things. I've got a set of utility classes that I reuse across several projects that I keep in a separate package/assembly. With project specific stuff, it's important to create a folder structure that reflects the programmatic structure of your packages, rather than dumping everything into some nebulous "global" namespace.

Hows this, I don't even use classes. Never liked it. I'd rather have a 500 line long onEnterFrame function than a class as I like having all the code I'm supposed to be working with all in front of me at the same time so that I can debug more easily if the need arises, as all of my code are in one place. I just use 'for' loops to place any code I need on individual MCs which are named like mc1, mc2, mc3.

It's just me though, wonder if anyone else finds classes weird.
(Not saying that classes suck or anything, just saying that Ifind that I can do without them)

[maskedMan]

I understand where you're coming from kkbbcute, as I once felt the same way. I think it depends really on how you structure your classes whether it's going to be easier to debug a 500 (or is it 5000) line onEnterFrame event than your class library.

For my money, it's much easier to debug classes than a giant procedural program. When objects are well-encapsulated and decoupled you remove needless dependencies, thus making a change in one place runs very little risk of causing unintended screwups elsewhere. Programming abstractly can allow you to swap class objects seamlessly either at compile time or at run time. While there was a time that I liked to be able to "see it all in one place", I've come to prefer only seeing what I need to see at any one time, and a good class structure lets you do just that.

Also, I suppose if you use the IDE exclusively to write your code and don't have a proper developer's tool like FlashDevelop (free) or FlexBuilder (not free) then managing a class library can be painful and require a lot of mental overhead that would be better spent on writing the code. The Flash IDE, since it doesn't recognize your custom classes in its auto complete and doesn't have a fully featured project panel, just makes writing a class-architecture harder than it needs to be.

[senocular]

For general, everyday, reusable classes, I put them in the standard, reverse-domain package structure starting with com.senocular followed by, if possible, the directory name that mirrors what its location would be if it was a native class in the player in the flash.* package. For example, my VirtualMouse class is located in package com.senocular.ui since in flash, most mouse-releated classes are located in flash.ui.

When working with project-specific classes, the same convention is used if the project has its own domain. For example I have a little Flash app with its own domain and its classes are all stored in com.myavatareditor.* because that's where it lives.

If a project does not have its own domain, it usually just gets a single top-level package directory named after the project itself. An example would be something like (now looking at one of my smaller projects) creatures.*.

If any project is to use classes from another source, such as the creatures app needing to use something from com.senocular.*, I would physically copy those com.senocular.* classes over to my creatures project directory. This does a couple things. This gives me access to all required classes in one, easy to find location, makes it easier to package up all source code with its dependencies if needing to give it to someone else or post somewhere publically, and keeps changes from that original code affecting the project since it has a copy of that code in a state where it is known to work for that project.

So... all my general-purpose classes I have somewhere on a common place on my hard drive, but no project actually uses them from that location. Instead they have copies of those classes in their respective project directories with other com.* classes or their own projectname.* classes.

That actually reminds me. In cases where I have projects with classes I think would be reusable or useful in other places, I'll usually throw them into com.senocular.* which I've wanted to do with some of the creatures classes for a while but never have.

[-Ev-]

I've got a very similar approach to senocular. All my personal reusable classes live in a Code folder on my hard drive that is simply a library of all classes I've written and felt were worthy of reuse. Root directory is com.evanwarner, and past that they are organized by category; data, layout, math, motion...whatever. Any time I want to use one of them, I copy it to my project's development folder.

My core belief is that any classes that collaboratively perform a job should be isolated in a package together. Methods and variables defined as internal should only be accessible to classes that will use them. Any standalone class that performs a job by itself can sit in the same package as other standalone classes, since all access is either public, protected or private.

A project's package organization is the same as my library...com.evanwarner followed by packages according to function of the classes.

[dimpiax]

I have such structure of my projects:


Project:

+ classes

+ ...
+ com.project.view
+ ...

+ deploy

+ data
+ assets
main.swf

It's very useful

[Robbus]

Out of interest where/when/why did 'com' become the generally accepted default name for the top level classes directory, why not 'classes' for example, or even just 'c'?

Cheers,
Rob

[-Ev-]

It was in effort to make package names unique and create a standard naming convention. Your website URL is unique, so it was a good candidate to use for package naming. It also sort of provides a way to find the author. It was reversed to com.* for two reasons:
1. To provide a more common root folder for packages instead of having all these unique names.
2. To prevent the possible confusion of seeing myurl.com. We automatically see that as a web address, but com.myurl is obviously not a web address.

I'm actually not sure if AS package naming was the first instance of this convention. I've seen it used other places. If you're on a Mac, go into your preferences folder, you'll see that a majority of the preference files are named com.apple.*.plist, com.adobe.*.plist, etc.

[Robbus]

Thanks Ev, I should've said mine was a more generalised question. So what did developers use before the whole internet thing as obviously there wouldn't have been .coms for us all to get excited about?!

Cheers,
Rob