Dr. Dobb's Journal - July 2008 - (Page 28)

Core Technology EVENT-BASED ARCHITECTURES Figure 6: Typical coupling diagram of an event-based system. continued from page 26 Figure 7: SystemBrowser UI. 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; see “Resource Center,” page 3.) 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. DDJ 28 Dr. Dobb’s Journal l www.ddj.com l July 2008 http://www.scitools.com http://www.scitools.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - July 2008

Dr. Dobb's Journal - July 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook Engineers Without Borders Conversations Patricia Tries Event-Based Architectures Graphs Versus Objects Lock-Free Queues Dr. Dobb’s Architecture & Design World Java and the Nokia N10 Internet Tablet Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - July 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.