Software Architecture Questions

[Alphabit]

I'm wondering, is dispatching and catching events a bad design decision?
I guess it kind of forces other classes to know about the events being dispatched... It makes the program a bit complicated to understand. What do you think? Are callbacks a better option?

Also, I've had trouble with this for a while now; How do you know where to instantiate classes?
Should you instantiate all the classes in a Main class and pass the low-level classes to others via constructors or is it OK to instantiate a class directly in another class which isn't the main class?
Which is best?

Cheers

[GustTheASGuy]

Long time no see.

Callbacks would be just as complicated if there was a complex event system.
You construct classes when and where you need them. >.>

[elbekko]

Well, it's up to the programmer to fully know the interface he's using. If that could throw an exception, you should know about it and be ready to catch it. The nice thing about exceptions is it's all handled by the language, and you can catch them wherever you want. Callbacks make this a bit more complicated IMO.

[StarCleaver]

At 6/3/08 09:56 PM, Alphabit wrote: I'm wondering, is dispatching and catching events a bad design decision?
I guess it kind of forces other classes to know about the events being dispatched... It makes the program a bit complicated to understand. What do you think? Are callbacks a better option?

It really depends on what you are trying to do. By dispatching and catching events, you need a fairly stable event model because small changes will potentially cause changes to propagate to all event "catchers." If you plan ahead and you forsee few changes, this may not be bad.

On the other hand, if you forsee a lot of changing, the callback model might be better. With callback, all of the functionality regarding the catching of events is centralized in the registry (the class to which other classes will register callbacks). Callbacks also tend to make the system more modular, because the only coupling between the caller and receiver is a single interface containing an executeAction() type of method and a single interface with a registerListener() type of method. Also, depending on how complex your system is, the callback model can mask a more complex event model through the loosely coupled interfaces.

Also, I've had trouble with this for a while now; How do you know where to instantiate classes?
Should you instantiate all the classes in a Main class and pass the low-level classes to others via constructors or is it OK to instantiate a class directly in another class which isn't the main class?
Which is best?

Again, it depends on what you are trying to do. There are also problems with each approach. By instantiating all of the classes in a main method, you are keeping all references in a single place. This means that the objects will have a long lifespan if all the references are maintained in a single place (e.g. the main class). This is bad for memory management, because the objects will live a longer life even if they are not being utilized. The use of a main class also breaks some fairly common OO practices in that an object should only know about things which it will actually need. In your main class model, all the classes in the chain of dependencies must know about the other classes, because you are passing them in when you construct the objects.

The other approach of classes instantiating other classes is probably your best bet. It will make the code the cleanest and will break dependencies among objects that do not need to know about each other. Its best to draw a class diagram and map out what classes will need other classes. With such a diagram, you can more easily see where to instantiate classes when needed.