Design patterns

[sekasi]

I guess my question is just strictly what I should rework to fit a certain design pattern or if I’m already classified as one. I’m trying really hard to implement some sort of continuity with patterns in my code but honestly I usually end up just structuring it with classes without that much backbone.

Here’s the current setup;

Document class sets up Classes A through D. They are all extending sprite and contain certain visual elements, grouped up by ‘type’. They all have more than just visual elements in them however. (Class C for example has a few subclasses and loads content)

Class D is special because it has interaction in it. That interaction kind of affects everything so what I’m currently doing is dispatching a custom event to the document class that in turn fires the appropriate methods in Classes A through C.

Everything works fine, but I have this itching feeling at the back of my neck saying I’m doing something wrong. Am I kneecapping myself here? Just curious.

[devonair]

Wow… I just keep running into you today…

It’s difficult to really answer without knowing what the purpose of all the classes are, but it seems to me that just by the fact that you’re passing events to the document class to let it handle the bulk of the work that you’re pretty much on the verge of MVC… Perhaps if you could sort out the visual elements from the actual data it would be a more pure version of MVC. Personally, I never get too hung up on design patterns. Unless I’m trying to do a job that I know has a certain pattern created just for it or I sit back and look at what a big pile of code and think “what a freakin’ mess” (which may be what you’re doing)… Seems when I try to force myself to follow a predetermined pattern though, my scripting becomes awkward and stilted and more convoluted than if I had allowed myself to organize it the way originally intended. They can be helpful when working with others though because you can just kind of mention the name of the pattern and everyone will have at least a vague idea of what’s going on…

[sekasi]

Yeah. You’re absolutely right. I just try to stick with things I know such as Singelton, Proxy or Composite patterns which are easier to oversee since they are more of a ‘per class’ basis.

When it comes to stuff like factory, MVC and it’s friend that more apply to a per-project basis pattern, I tend to get a little … um scratch head

thanks for the reply though, I’ll look into what breaks the MVC pattern with the help of Joey Lott’s book

[dthought]

I’m not a traditional programmer, so I don’t really know about official patterns and coding methodologies, so I can just relate what I do.

The first is that I can always see more clearly what I probably should be doing once I’ve started on something. Partly that’s experience, partly that’s that I only think ahead so far, partly it’s learning so much along the way, and partly it’s because of a fastidious desire to do the best I can with everything I do

I try to see things as a kind of ecosystem, and I often draw out what I believe the “overarching” elements are, how they inter-relate, how they behave and so on. Nothing too technical, just a kind of “mind map” of the structure and flow. Sometimes new things will crop up as I’m coding away, so I try to fit those in.

As far as your design is concerned, I’d be wondering why you’re sending messages through the main document class, when you could just have classes A through C listening directly? If it were me, I’d be thinking “Is it more efficient to have one listener in a central location who then dispatches multiple things to my other classes?” and maybe that might be okay as a solution… but from AS3’s mentality that I’m still trying to get to grips with myself, even in that case you should still have A - C listening to the document class for that event… so hmm. Yes. I think you should dispatch the event in D and have A - C listen to D, and not the main document class. It may mean a few more listeners are in play… so just remember to clean up after them when needed

So that’s my thoughts. Take them as you wish

[sekasi]

Uuum not to sure about that, I was under the impression that you should try and limit the coupling between classes as much as possible and having each class listening for the other seems to imply tight coupling, no?

[dthought]

Not particularly, I don’t think… but if you did it the way you are suggesting, eg. on your document class

function documentListener(evt:Event):void
{
    classAinstance.doSomething();
    classBinstance.doSomething();
    classCinstance.doSomething();
}

Then that is a really naughty intermingling - even though the document class “manages” things, telling explicit children what to do is, from what I understand, not desirable (though I believe that DisplayObjects may be a slight exception, eg. dealing with those pesky display list children).

Anyway, as I said, that’s just the way I understand things

[sekasi]

Interesting. Quite frankly I’m still shaky on concepts like these. I know how to accomplish things, but not necessarily the best practice.

I don’t know! Anyone else have any thoughts?

[devonair]

Personally, I would probably do it the way dthought just said is naughty… heh… I understand why it probably shouldn’t be done that way, but I find that would be looser coupled than if you were to pass instances of objects to various other object instances and have them listen for events that way. If though you’d really like to completely decouple the whole kit and kaboodle, go for the command pattern… If you have Joey Lott’s book, I think there’s a good example in there… Basically, you could create a ConcreteCommand instance for classes A - C (which hopefully are written to an interface that implements a doSomething() method)… Eventually though something would have to call the Command’s execute() method (namely the documentListener() method mentioned by dthought). This adds one extra level of abstraction and decoupling but essentially accomplishes the same thing…

[dthought]

I was having a think about this before I went to sleep last night, and I think that what I might be interpreting is a kind of “idealised OOP” versus actual, practical OOP.

I thought, hang on, if events are all we’re supposed to use to communicate, what’s the point of things like getters and setters? I know some OOP purists see these as pointless when you should do your encapsulation (class data protection) via methods… hmm. Maybe it’s okay for a parent (eg. document) class to call on methods of children explicitly, but for inter-child relationships to use listeners.

That seems to make sense from the point of view, that you should ideally be able to separate a class and reuse it elsewhere. If you have any explicitly named instances, or you’re passing references to a second, not necessarily related sibling class, then you could end up creating a whole heap of mess (and pain) that you didn’t intend to

Still, I’d be interested in hearing others’ thoughts on this too

[Anogar]

[QUOTE=sekasi;2354216]Uuum not to sure about that, I was under the impression that you should try and limit the coupling between classes as much as possible and having each class listening for the other seems to imply tight coupling, no?[/QUOTE]

No, you’re totally right, that sort of tight coupling should be avoided. Interaction should be pretty much vertical, if that makes sense. Classes should interact with their children, and dispatch events to their parents, but they should not be relying on interacting with their siblings - otherwise you’ll end up with inflexible applications that require that precise coupling - which is just not ideal.

[QUOTE=dthought;2354217]Not particularly, I don’t think… but if you did it the way you are suggesting, eg. on your document class

function documentListener(evt:Event):void
{
    classAinstance.doSomething();
    classBinstance.doSomething();
    classCinstance.doSomething();
}

Then that is a really naughty intermingling - even though the document class “manages” things, telling explicit children what to do is, from what I understand, not desirable (though I believe that DisplayObjects may be a slight exception, eg. dealing with those pesky display list children).

Anyway, as I said, that’s just the way I understand things :)[/QUOTE]

Actually, that’s not “naughty” at all. Having an exposed interface (a public method, or set of methods) is a perfectly acceptable and even encouraged practice.

Subclasses should be protected in that no other class should be able to ‘break’ them. Having them be self-contained as possible is ideal, but what is most important is that the class’s methods and variables cannot be abused in any way - i.e. variables cannot be set out of bounds, submethods cannot be called out of order, that sort of thing.

Classes should ideally maintain **internal **sovereignty - but they most certainly can and should interact with their parents and children. The important thing is that they interact in predictable (and well defined) ways.

edit:

As far as the initial question, your setup is fine. The thing I would change is that you should probably fully extract the data from the visual elements. I like to use a Singleton that holds my XML data. My Document class typically instantiates the Singleton and tells it to load the data, and once the data is loaded, it goes about the rest of the application setup - now that the data for the application is available.