By bus or... on foot?

So I've been receiving some mails with some questions and suggestions. And, to be honest, I'm confused. Too many ideas. Brainstorming is working!!

Some of the ideas were about the site design. I've taken some into account (a friend of mine helped me with the HTML, well, that's difficult!). Expect some more changes in the coming weeks as time permits. Entries are more organized now in (hopefully useful) categories. I've also included some links to other interesting blogs, too. Feedback is greatly welcome.

So I decided to share with you my concerns, just once more, in order to try to clarify things. (So, please, help me here).

There we go:

Question I: Is this "Event Bus" a new "pattern" or not?

Someone suggested this "event bus" approach was some sort of pattern. I've been reviewing the "Observer Pattern" in my copy of "Design Patterns" during this weekend. And reading Design Patterns I've found interesting stuff I'd like to share with you. Just to try to clarify my thoughts.

Let me quote Design Patterns just a moment, please:

"Define a one-to-many dependency between objects so that when one object changes state (our macro-components), all its dependents (listeners) are notified and updated automatically"

D'oh!! One-to-many what?? Dependencies, you say?? Wait, wait, wait. Wasn't it "Find dependencies... and eliminate them"?? Isn't that the problem? Yes! The Observer Pattern is the problem! The macro-components of my Swing applications (the Observables/Subjects) keep "one-to-many" dependencies with the listeners (the Observers).

That's why my StatusBar is a listener of the FilesystemViewer, and the FilesystemViewer is a listener of the Menubar! And the Editor is a listener of both the FilesystemViewer and the Menubar! And that's why I'm having chains of listeners, and thus chains of dependencies. And that's why I'm having so many problems with large Swing applications!!

So let's define a new pattern!! Let's call it the Event Bus Pattern!! Pretty much as Martin Fowler calls it an Event Aggregator.

Well, er... no.

That would be just plain Overpatterning, I think. Isn't it?

Let's keep on reading.

Please allow me to quote here an excerpt of Design Patterns. Again. Please bear with me.

Encapsulating complex update semantics. When the dependency relationship between subjects (macro-components) and observers (listeners) is particularly complex, an object that maintains these relationships might be required. We call such an object a Change-Manager (i.e., the Event Bus equivalent). Its purpose is to minimize the work required to make observers (listeners) reflect a change in their subject (macro-components). For example, if an operation involves changes to several interdependent subjects (macro-components), you might have to ensure that their observers (listeners) are notified only after all the subjects (macro-components) have been modified to avoid notifying observers (listeners) more than once.

Design Patterns - Implementation, paragraph 8

So, as you can see, the Event Bus was already defined as early as 1994!! (Well, I think the "Change-Manager" is not exactly an Event Bus because the one-to-many dependencies are still kept there between Subjects and Observers, but it's a rough approximation, thoughts?).

But, wait, there's even more. Go see section Implementation.7 and you'll see aspects defined, something similar to "topics", "interrupt-levels" or "channels". Isn't it? (Or is it that I see topics everywhere? ;-) )

But, wait, wait, there's even more!!

At the end of section Implementation.8 I read:

... ChangeManager (EventBus) is an instance of the Mediator pattern. In general there is only one ChangeManager, and it is known globally. The Singleton pattern would be useful here.
(Note that ELF is using singletons for their event bus).

So, as you can see, Mediators were already in place in Event Buses in 1994!!

Question II: Is this "event bus" really needed for big Swing apps?

Jim asked if this "event bus" approach is required for big Swing applications.

This is, shall we go by bus or just on foot with simple Listeners? I'd say this "event bus" is not needed, but may be helpful (what do you think?) (In the sample application there's an asynchronous listener for logging events to System.out, for instance, and building it is extremely easy).

Typical medium-size Swing applications have usually some sort of controller. Usually mixed with view logic. You can see an example in the Mandelbrot Explorer source code. Take a look at the MandelbrotViewController.java class. That's a ZoomListener, ShiftListener, PropertyChangeListener and ProgressPaneCancelListener. All in one. It aggregates events from different views. And then it coordinates them. It's a mediator instance.

But by doing things through "event buses" you may make things easier. It's easier to encapsulate these "mediators" in separate classes, attached to the bus. Don't you think?

Question III: Aren't we generating tons of events?

Well, it depends. Don't you generate lots of Actions? I'd say Swing "Actions" encapsulate event listeners, right?. Actions tend to be more powerful "ActionListeners". So, what about changing Swing actions into, say, ApplicationEvents through the bus? EditAction, OpenFileAction and the such would then be transformed into EditActionEvents, OpenFileActionEvent or, as Tim suggested, EditCommandEvent, OpenFileCommandEvent.

So, from my point of view, yes: it generates lots of events. But that's not a problem, I think. Thoughts?

Example

UITopics demo Screenshot

I'm almost done with the sample application (JDK5.0 Java Web Start). I'll talk of it in the coming weeks as a basis for discussion. It's built with Type I aggregators (controllers with instances to the view). Source code is available (uitopics and JDK5.0 required).

I think mediators (package net.java.uitopics.demo.controllers) are not that difficult to read, right? Any suggestions?

Cheers,
Antonio

Comentarios:

why using Type I aggregators? ..this seems like a bad approach, for reasons mentioned in a previous post when you asked which is preferred.

Enviado por codecraig en septiembre 26, 2005 a las 02:39 PM CEST #

Hi

Yes, I aggree Type II aggregators are more powerful. Now that we have a sample application with Type I aggregators the next step is to change those Type I aggregators into Type II aggregators. That'll be what I'll be talking about. I'm busy, so maybe it takes a couple of days. I'll let you know when it's ready.

Cheers
Antonio

Enviado por Antonio en septiembre 27, 2005 a las 04:41 AM CEST #

sounds good!

Enviado por codecraig en septiembre 27, 2005 a las 06:12 AM CEST #

To chime in on Question 2:

I think an event Bus or similar idiom "helps" a great deal in larger Swing applications (UI apps in general really), by helping assign responsibility and ease flow control. When events of a certain type are handled by mediators of a certain type it's a lot easier to understand (esp. new programmers) where to add code in case of enhancements and where to start looking in terms of bugs. It becomes a lot easier to put every thing in it's place and have a place for everything...

Question III: Aren't we generating tons of events?

If you're talking about the number of events being fired while the app is running, not really. If you're talking about the number of events that we have to create in order to successfully assign the responsibility of event handling to certain mediators, yes. The amount of events we have to create is outweighed, I think, by the amount of flexibility that the events provide.

I'm curious to see how the application will handle events being vetoed or veto like behavior for command events... Tim

Enviado por Tim Osten en septiembre 27, 2005 a las 09:41 AM CEST #

Enviar un comentario:
Los comentarios han sido deshabilitados.
About

swinger

Search

Archives
« abril 2014
lunmarmiéjueviesábdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Hoy