Hooking the Parts Together
Again, an EBA relies on parts that are independent of each other and that communicate using event notifications. If the parts are essentially oblivious of each other, then how do the parts get created and wired together? Good question. Before answering it, let's look at how things work in traditional object-oriented systems. The operating system calls a program's entry point, which typically instantiates a top-level class, which in turn instantiates other intermediate-level classes, each of which might instantiate other intermediate-level classes and low-level classes. In GUI programs, the top-level class is often the main window. Intermediate-level classes tend to be those that handle important functionality. Low-level classes generally are domain-specific types used by and exchanged between intermediate-level classes. For example, in a word-processing program, a SpellingChecker class might be an intermediate one and a Paragraph class might be a low-level one.
If you diagrammed the instantiation sequence of a traditional OO system, you would generally end up with a single-rooted directed graph whose root is the top-level class; see Figure 5. The graph implicitly shows coupling, because a class that contains code to instantiate another class is coupled to that class. The top-level class is hence directly or indirectly coupled to all the other classes in the system. The intermediate-level classes are directly or indirectly coupled to many other intermediate-level classes.
In EBAs, much of this coupling is avoided by using a special type of part called a Builder (not to be confused with the Builder OO design pattern). An EBA Builder is called by the program's entry point and has one job—to create instances of all the intermediate-level classes. Intermediate-level classes are no longer responsible for instantiating other intermediate-level classes. Intermediate-level classes communicate with each other exclusively using event notifications. When the notifications use untyped calls, there is no type coupling between the classes. The coupling diagram of this kind of system has a star shape, with all the low-level classes in the middle and all the intermediate-level classes at the periphery; see Figure 6.
The intermediate-level classes at the periphery of the diagram are not coupled to each other. For these classes to interact, notification paths between them must exist. These paths are created using another special type of part called a Binder. At system startup time, after the Builder has created all the intermediate parts, the Binder takes over and wires them together. When the Binder is finished, the system is ready to perform its intended functions. Both the Builder and Binder have access to all the intermediate classes of the system and hence they are coupled to those classes. The coupling diagram for the Builder and Binder system is star-based, but this time the Builder and Binder are in the center and the coupling arrows are directed outward, towards the intermediate-level classes.
SystemBrowser: An Event-Based System
SystemBrowser is a small, event-based program I wrote that works somewhat like Windows Explorer. The program has a GUI with a main window divided into sections: a top toolbar, a bottom status bar, and a middle section with left and right panes. The left pane shows a directory tree, the right the files and subdirectories in the selected directory; see Figure 7.
Figure 4 is the complete wiring diagram for SystemBrowser. FormMenuToolbar contains a menu and toolbar, which are created by the Builder, then attached to the main form at startup time. In Figure 4, notice that the main form is missing. An accident? No. In SystemBrowser, the main form does nothing more than hold the various UI elements together, and doesn't participate in the handling or dispatching of notifications in the system.
I wrote a C# implementation of SystemBrowser. The Builder instantiates all classes and maintains references to them, holding them in scope for the lifetime of the application. The Binder wires all the objects together. To keep things simple, I combined the Builder and Binder code into a single class called BuilderBinder. Listing One shows the Builder code and Listing Two shows the Binder code. (Both listings are available online at www.ddj.com/code/
What controls the building and binding of the system is the startup code in the EntryPoint class (Listing Three, online). Listing Four shows the salient code of FormMenuToolbar, DirectoryTree, and DirectoryContent, respectively. I omitted the details of how DirectoryTree and DirectoryContent populate themselves because I wanted to focus on what was important about SystemBrowser, in terms of its event-based design. The complete source code is available online. Looking at the code, you'll notice a number of methods starting with the word "Fire". I use a separate Fire method to handle the firing of each event type, avoiding having event semantics scattered around, while having a single place to set breakpoints when testing an event.
Conclusion
The larger a system gets, the more you can benefit from Event-Based Architectures. The individual parts, be they classes or components, have little or no type coupling to the rest of the system. This is especially important for testability. EBAs are eminently testable. They can be tested incrementally and can be developed using a test-driven approach. You can develop and test every major part of a system in isolation. Very cool.
Over the years, I have developed many different types of software systems using EBAs. People sometimes find it perplexing that the salient classes in an EBA have no associations between them, but this is often a good thing because EBAs reduce coupling in order to reduce complexity. I have found that signal wiring diagrams are a good way to document and model EBAs. Although they are different from most of the diagrams you're probably seen before, they are easy to understand and easy to create.
