I got code duplication...

[Flash Gordon]

http://img142.imageshack.us/img142/4729/classdiagram1si3.jpg


So let me explain my situation. I have to build 4 sites that will use very similar features. Within those 4 sites, there will be several galleries for each site, say 8 galleries. Each gallery will have a linkage, and will look and function slightly different. However, within a single site each image transition will be the same for each gallery. The image transition is only different from site to site. So I have 4 sites, and each site has 1 transition associated. Each site as 8 galleries that use the 1 transition.

Ok so my problem is, I have a bunch of code duplication. Each GalleryModuleX is a linkage class that basically sets the specific properties for the superclass. GalleryModuleX is specific to each site, where as the other class provide a framework. The problem is each GalleryModuleX classes are using the same code over and over and I don't know how to get rid of it. I keep copying and pasting this stuff.

protected function imageClose(e:Event):void
{
// performs an image effect
}


/**
* Override the initial loading of the first image
*/
override protected function mainLoaded(e:Event=null):void
{
// here I'm overriding the default behavior for the BasicGallery
// so that the specific effect is set up
}

override protected function center(obj:DisplayObject):void
{
// center the effect
}


/**
* Override the onComplete method to make the new picture wait for the new animation to be complete
*/
override protected function onComplete(e:PreloaderEvent):void
{
// do the opening transition when picture loads
}


Since I'm overriding method, how do I encapsulated this code so I only have to write it once?

[Assertnfailure]

So the only reason you're subclassing is to apply transition in/out effects?

If you want to template recurring logic, you should just use an abstract class as the super class.

[Flash Gordon]

Thanks for the reply. What is happening is BasicGallery and GalleryX are class that take care of all the gallery functionality for each site. It has about 10 properties that are instantiated but undefined. "GalleryModuleX" just defines the properties and "GalleryModuleX" gets linked to in the Flash GUI. Does that make sense?

So I have BasicModule, BasicGallery, and GalleryX all in a com.framework.modules.galleries package and they are all abstracts. Where GalleryModuleX subclasses the framework but is specific to each site. mysite.modules.galleries package.

I'm not sure where in the chain I could add the "abstract class as the super class" that you are referring to.

[Flash Gordon]

anymore thoughts out there?

[Assertnfailure]

I know this is a little late, but.....

From what it sounds like to me, you are already using abstract classes in a template pattern arrangement (BasicGallery). Why not insert the common logic into BasicGallery, or insert another abstract class into the inheritance change?

[Flash Gordon]

it's never late to learn :)

I actually haven't done much with it since then, but I think today I'm going to try and redo the structure to make it use composition rather than inheritance.

The reason why I can't I can't "insert the common logic into BasicGallery" (at least in my mind) is that BasicGallery belongs to the "framework" as where "GalleryModule1" belong to the specific site. Each site has it's own GalleryModule1 but all sites share the BasicGallery. Since GalleryModule1 is inheriting from BasicGallery I can't make it inheritant at the site level since it is inheriting at the framework level....tough to explain without see it.

I'll give it a shot with composition and post back my results.

Thanks again for your valuable input. I always learn something from you posts!

[Flash Gordon]

update:

It nearly a complete restructure. In stead of templating the classes, I'm using composition and the Gallery1, GalleryX have been a storage facility for the data and doesn't direct the displaying of the data. That is handled at the GalleryModule level. This looks very promising, and it allows me to have inhertiance where i need it.

[Flash Gordon]

It actually worked out really well. I wish I could subclass a "template" class and have that superclass have acess to my linkage movieclip. :(

[Assertnfailure]

It actually worked out really well. I wish I could subclass a "template" class and have that superclass have acess to my linkage movieclip. :(

Why not?


class SuperClass{

private var instance:SuperClass;

public function SuperClass(symbol:Class){
instance = new symbol();
}
}



class SubClass extends SuperClass{

public function SubClass(){
super(SubClassSymbol);
}
}


Something like that? I haven't really worked in Flash CS3 in a while, so I might not be thinking the same thing.

[Flash Gordon]

Some ma na b**ch....

Thanks dude. This is extacly what I needed.

package
{
import flash.display.MovieClip;

public class SuperClass extends MovieClip
{
private var _subclass:MovieClip;

public function SuperClass(subclass:MovieClip)
{
_subclass = subclass;
}

public function hideOval():void
{
_subclass.oval.visible = false; // where oval is a displayobject inside of subclass and subclass linkage is set in library
}
}
}


package
{
import flash.display.MovieClip;

public class SubClass extends SuperClass
{
public function SubClass()
{
super(this);
}
}
}


// in fla
scene.addEventListener(MouseEvent.CLICK, onClick);
function onClick(e:MouseEvent):void
{
scene.hideOval();
}


I think that right there has been my problem all a long!!!!

[Assertnfailure]

Ahhh, well if you're just passing this into the constructor, then you should be able to just use this instead of _subclass in your superclass. :]

[Flash Gordon]

What do you mean? When I try it like that I get:
1119: Access of possibly undefined property oval through a reference with static type SuperClass.

[Assertnfailure]

oh...oval belongs to the subclass but not the superclass?

hmm....in that case, I'd probably be passing the instance of oval to the superclass, rather than "this" since your superclass is polymorphing instance to a class type that might not satisfy the oval requirement.

[Flash Gordon]

yea.

I tried doing it that way. Really oval is just a movieclip in a parent movieclip "scene" with "scene" linkage set to SubClass. As such, SuperClass doesn't know about oval. It's a simplification (of course), but I like this method since oval isn't really a property of the SubClass, but just a displayobject inside of it. I tried the other way earlier and it was pretty messy.

It probably does go against good OO rules, but I think in this case I'm gonna break the rules. For instance, there is no guarantee that oval with even exist in _subclass. However, since these are linkage movieclips I'm dealing with specific to an swf (which means the code isn't very much reusable), I feel okay doing this since I am the one authoring what is in them. Basically, SuperClass becomes an abstract class for several of my linkage movieclips that share the same display objects.....That's my reason for breaking the rules.