PDA

View Full Version : Organising Classes in the most effective way


Quintin_S
08-27-2010, 12:34 AM
Hello o ye gurus,

I've got a question about general best practices involving classes and organising your project. I expect that there probably won't be any "right" answer to this, so please give your opinions and insights! A good discussion usually gives a lot more insight than a clear cut yes or no answer.

I've been trying to get my head around organising my classes effectively. Often I can decide where a particular method or property that controls a certain part of an application should rightly go.

For example:

Say we have an ImageGallery class, which should contain many instances ImageThumbnail class. When pressed, each ImageThumbnail should display a larger version of the image.


Should the code for displaying the larger image be a method of the ImageGallery class or the ImageThumbnail class?
Should the loader that loads the image into the thumbnail sit outside the thumbnails in an ImageGallery and load them in one by one, or should each thumbnail have a Loader that loads its own thumbnail?


The question gets even more complex when you start adding other elements with functionalities that overlap with these and that inter-reference other classes; for instance, like a button for hiding the image gallery. Should the button be part of the ImageGallery class or its parent?

When I'm thinking about this, I usually can't make up my mind about which route is the best one and end up taking casting shortcuts, which usually produces some confusing, messy and inelegant code.

I'm not a developer or a programmer by training (designer all the way), so maybe the best way is obvious and I'm just too stupid to see it... What would be your advice for getting out of this mental tangle? Are there some basic principles that are missing from my education? I'd greatly appreciate any insights.

Thanks! :)

tadster
08-27-2010, 03:16 AM
* Should the code for displaying the larger image be a method of the ImageGallery class or the ImageThumbnail class?
* Should the loader that loads the image into the thumbnail sit outside the thumbnails in an ImageGallery and load them in one by one, or should each thumbnail have a Loader that loads its own thumbnail?


1 - ImageThumbnail class - I think everyone would agree.
2 - You should have the fewest Loaders possible, so ImageGallery.

Quintin_S
08-27-2010, 04:06 AM
1 - ImageThumbnail class - I think everyone would agree.

Why is that, though? Performance reasons?

What if you want only one image to be enlarged at a time? It seems "right" to me that the info should be stored in ImageGallery, as well.

2 - You should have the fewest Loaders possible, so ImageGallery.

But is it even possible? As far as I know, you can only load images into a Loader object and then place the Loader itself onto the stage.

Like I said, I'm a complete noob so any lectures on architecture would be very welcome.

maskedMan
08-27-2010, 01:25 PM
But is it even possible? As far as I know, you can only load images into a Loader object and then place the Loader itself onto the stage.


private var loadedContent:MovieClip;

private function onLoadComplete(e:Event):void{
loadedContent = e.currentTarget.content;
loader.unload();
this.addChild(loadedContent);
}
// ^ That's how you reuse a loader.




I wouldn't say you use OOP for performance reasons. In fact, OOP overhead can be a drag on performance at times. You use it as an organizational paradigm to manage the complexity of a project in your own mind, and in the minds of others. When you're doing it right, it's supposed to make programs easier to modify, update, or extend, and it shines when those considerations are more important than a microsecond here or there.

maskedMan
08-27-2010, 01:42 PM
EDIT:

Oh, as to why you'd make displaying the image a function of the thumbnail class, I'd say the answer lies in the way you framed the scenario. Because you want the thumbnail to blow up into a larger image, and perhaps you want it to do this in a special way, the thumbnail would need to know how this is done. You'd delegate that responsibility to the thumbnail, because that's the thumbnail's business...

If on the other hand you said that the larger image appears in a new display object, completely distinct from the thumbnails, then that responsibility would belong to the gallery (or maybe even the gallery's owner!). In that scenario, the thumbnails would be just dumb, glorified buttons whose events you listen for.


Or, maybe there's nothing special about the way you're showing the larger image? Maybe you just want to scale the thumbnail? In that case, you might instead have a third class whose only responsibility is to scale things, and when the thumbnail is clicked the gallery feeds the thumbnail to the scaler class?

mindprism
09-13-2010, 10:48 AM
Here is something that might help you. A couple of code structure templates. I have an editor that will do an automated 'create member' dialog for each context-- ie, when your behind the semicolon. You will also see that each section has a # code that allows for incremental search navigation.

This is code behind template:

//C:\!mark\_flex4\kwgen\src\xx.as
//Z
//#links
//
//#> includes
//#[[##]]
//#imports
import mx.core.*;
import mx.events.*;
import mx.utils.*;
import mx.rpc.events.*;
import mx.containers.*;
import mx.controls.*;
import mx.binding.utils.*;
import mx.styles.*;
import mx.collections.*;
;
//# events
//#out events
;
;
//#, members
//#+, public members
//#+*, public static members
;
//#+*@, public static const members
;
//#+*', public static singleton members
;
//#+*&, public static bindable members
;
//#+@, public const members
;
//#+', public singletons members
;
//#+&, public bindable members
;
;
//#%, protected members
//#%*, protected static members
;
//#%*@, protected static const members
;
//#%*', protected static singleton members
;
//#%*&, protected static bindable members
;
//#%@, protected const members
;
//#%', protected singletons members
;
//#%&, protected bindable members
;
;
//#-, private members
//#-*, private static members
;
//#-*@, private static const members
;
//#-*', private static singleton members
;
//#-*&, private static bindable members
;
//#-@, private const members
;
//#-', private singletons members
;
//#-&, private bindable members
;
;
//#. properties
//#+. public properties
//#+*. public static properties
;
//#+*@. public static const properties
;
//#+*'. public static singleton properties
;
//#+*&. public static bindable properties
;
//#+@. public const properties
;
//#+'. public singletons properties
;
//#+&. public bindable properties
;
;
//#%. protected properties
//#%*. protected static properties
;
//#%*@. protected static const properties
;
//#%*'. protected static singleton properties
;
//#%*&. protected static bindable properties
;
//#%@. protected const properties
;
//#%'. protected singletons properties
;
//#%&. protected bindable properties
;
;
//#-. private properties
//#-*. private static properties
;
//#-*@. private static const properties
;
//#-*'. private static singleton properties
;
//#-*&. private static bindable properties
;
//#-@. private const properties
;
//#-'. private singletons properties
;
//#-&. private bindable properties
;
;
//#^ main initializer
;
//#! commands
//#+! public commands
;
//#%! protected commands
;
//#-! private commands
//#-! private init commands
;
//#-! private reset commands
;
//#-! private util commands
;
;
;
//#\ events
//#+\ public events
;
//#%\ protected events
;
//#-\ private events
//#-c\ private control events
;
//#-r\ private remote events
;
//#-s\ private service events
;
//#-o\ private other events
;
;
//#? functions
//#+? public functions
;
//#%? protected function
;
//#-? private functions
;
//EOF


The class template is simular, but you get the idea.

spooner
09-16-2010, 06:36 PM
I have no idea what I just read (>_<)

Quintin, to answer your original question I would completely disagree with tadster.

First question:
You definitely want a thumbnail class of some sort. There are some different ways to do it, but generally you want the thumbnail to indicate that it was selected. Once it is selected, it would trigger the code to show the Image in the ImageGallery. Best way to do this is by throwing an event.. the thumbnail sends an event indicating it was selected, and the ImageGallery is listening for it (if it wants) and responds. This makes it very easy to control the behavior of actually showing the image in your Gallery class, manage thumbnails, when they are active, when the Gallery can respond, etc.

Second question:
It doesn't hurt to have multiple Loaders.. especially if you are loading thumbnails, its such a cheap operation to just throw it into the thumbnail class and load all. That said, if you want to manage a large large set of them, better to have a loading manager that then creates new thumbnail instances with each thumbnail loaded. The manager wouldn't need to reuse the Loaders (no reason to not just create new ones, the old will be GC eventually) but the advantage is to limit the traffic bandwidth at any one time, and load them in sequentially. You could easily have multiple loaders working at a time (like 3 or 5) and the loading manager simply loads the next thumb in the list as each one that's loading comes in.

I also have to agree with maskedMan, it really does depend on how you're using it. But I would refrain from loading in the full image in the thumbnail.. it is a lot more work to manage a tightly coupled relationship, and your ImageGallery class ends up being entirely about communicating between thumbnails, which you just plain do not need to do.