Extended Bridge Software Design Pattern

Software engineers are taught that they should separate form and function. This allows a user interface or front-end to be designed and implemented independently of the engine or backend. Using an abstracted interface class provides the opportunity to develop different user interfaces for the same back-end, as each new user interface will all be derived from this agreed upon abstracted interface. Using the Bridge pattern allows the user to also decouple the abstraction from its implementation, providing additional flexibility as they developed multiple user interfaces. However, user interfaces are typically designed as a single unit, the renderer, even the Bridge pattern refers to it as the ConcreteImplementor. This thesis concentrated on the implementation of the renderer and merged the Bridge pattern with another design pattern, the Presentation Model. The Extended Bridge pattern also includes support for the Single Responsibility principle; a construct that improves upon the Presentation Model by decoupling the logic and the data from the rendering code. In short the Extended Bridge is an object oriented pattern that provides an abstract interface, an abstract implementation with decoupled logic, data and rendering, that is flexible, maintainable, reusable and highly testable. Revision Date 10/25/2012 Acknowledgements I would like thank all of the Professors at Regis University for their support, guidance and knowledge. I especially would like to thank Dr. Richard Blumenthal for his patience as I crafted this thesis. My son Daniel deserves a special mention for proof-reading several revisions of this thesis. Finally to my new bride Sheryl and our merged families for letting me find time alone to complete this thesis, at a time when we were getting to know each other. EXTENDED BRIDGE SOFTWARE DESIGN PATTERN 4 List of Figures Figure Page 2.1. Separation of Form and Function. 11 2.2. UML notation for the Components pattern. 12 2.3. Model-View-Controller (MVC). 13 2.4. UML notation for the Bridge pattern. 14 2.5. UML notation for the Presentation Model pattern. 16 2.6. BankAccounts application demonstration user interface. 17 2.7. BankAccounts application full function user interface. 18 2.8. Diagram of the BankAccounts user interface design. 19 2.9. QuizMaster showing the questions. 20 2.10. QuizMaster showing the test results. 20 2.11. QuizMaster showing the tests. 21 2.12. Diagram of the QuizMaster user interface design. 21 3.1. The Extended Bridge pattern. 24 3.2. Architecture diagram for the BankAccount application. 25 3.3. Architecture diagram for the QuizMaster application. 26 3.4. Instantiation flow for the BankAccount application. 27 3.5. Instantiation flow for the QuizMaster application. 28 3.6. Architecture diagram for the BankAccount application. 29 3.7. Architecture diagram for the QuizMaster application. 30 3.8. Instantiation flow for the BankAccount application. 31 3.9. Instantiation flow for the QuizMaster application. 32 Revision Date 10/25/2012 3.10. Architecture diagram for the BankAccount application. 33 3.11. Architecture diagram for the QuizMaster application. 34 3.12. Instantiation flow for the BankAccount application. 35 3.13. Instantiation flow for the QuizMaster application. 36 3.14. Architecture diagram for the BankAccount application. 38 3.15. Architecture diagram for the QuizMaster application. 38 3.16. Instantiation flow for the BankAccount application. 39 3.17. Instantiation flow for the QuizMaster application. 40 4.1. Average Complexity per design pattern. 45 4.2. Distribution of Complexity per design pattern. 46 4.3. Average Number of Executable Lines per Method per design pattern. 46 4.4. Average Complexity per design pattern. 47 4.5. Distribution of Complexity per design pattern. 48 4.6. Average Number of Executable Lines per Method per design pattern. 48 EXTENDED BRIDGE SOFTWARE DESIGN PATTERN 6 List of Tables Table Page 4.1. Key metric values for the BankAccounts implementations. 45 4.2. Key metric values for the QuizMaster implementations. 47 Revision Date 10/25/2012 Extended Bridge Software Design Pattern When designing a user interface, is it possible to design it so that it addresses two specific problems? Can it be flexible enough to support different implementations, while ensuring that it maximizes testing, independent of the user interface implementation? When implementing the user interface with object-oriented technology, there is an additional requirement to take the Single Responsibility principle (Martin, 2003) into consideration. The Single Responsibility principle states “every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class”. The Extended Bridge pattern is an object oriented design that has been created to specifically address these problems, including providing support for the Single Responsibility principle. A typical user interface (UI) consists of windows or forms which contain three distinct elements, the code to render the UI (buttons, lists, text fields, etc.), the logic of the UI (what happens when you click a button) and the data that is rendered by the UI. Without the Single Responsibility principle having these three elements in the same class gives rise to the following problems:  Reduced Maintainability A change to any one element is likely to require changes in the other two to support it, making it harder to implement isolated changes. This in turn reduces the maintainability of the class.  Reduced Testability Whilst it is possible to write the logic and data elements of an application in such a way that each component can be unit tested in isolation, the UI related code is inherently very difficult to unit test. Firstly, it is difficult to test any visualization as it often needs to be judged by a human to see if it „looks right‟. Secondly user interactions are needed when trying to test UI components, such as buttons. If the EXTENDED BRIDGE SOFTWARE DESIGN PATTERN 8 code to render the UI is mixed with the logic and the data, the independent testability of the logic and data is lost. Automated UI testing solutions are available (Uispec4j, 2012), but because they tend to „mimic‟ the user interaction, they are either harder to setup and maintain than unit tests or they are only useable as integration tests because they need the entire application to be set up.  Reduced Reusability If the three elements of the user interface are mixed in the same class, it becomes a lot harder to make that code reusable. For example, if the data is included in the same class, any changes to the way the data is stored will necessitate changes in the way it is accessed by the rendering and logic code. Abstracting and encapsulating the data into an independent class makes it reusable. Including the Single Responsibility principle in the Extended Bridge pattern requires that the three UI elements, code, logic and data, be separated. The logic associated with the user interface components is decoupled from the code and the data. This provides two benefits. Firstly it allows different styles of user interface to be supported as the implementation now has a component that is just responsible for rendering the user interface; secondly it allows the logic to be tested independently of the user interface. Finally the data is decoupled from the implementation. This eliminates the need for the logic to have an intimate knowledge of the user interface and how to access the data that would otherwise have been stored there. Including the Single Responsibility principle provides the Extended Bridge pattern with increased maintainability, reusability and independent testability of the three UI elements. Revision Date 10/25/2012 Consider the following as a use case: A developer is asked to design a user interface that can be implemented on multiple platforms, with support for a full featured version and a demonstration (light-weight) version on each platform. Using the Extended Bridge pattern, as described in this thesis, provides the developer with the ability to create a design that is flexible enough to integrate the requested user interfaces, while maximizing testability. Two applications are referenced in this thesis, the first is an application to manipulate a simple bank account record system providing two user interfaces; the second is an application that manages quiz questions providing a user interface that contains interchangeable view components. The Extended Bridge pattern is based on the result of merging two existing design patterns. The Bridge pattern (Gamma et al., 1995) provides the flexibility, and the Presentation Model (Fowler, 2004) provided some support for the Single Responsibility principle. The Extended Bridge pattern builds on the flexibility of the Bridge pattern, which abstracts not only the functional requirements but also the implementation details, so that the two can be modified independently of each other. It merges this with the Presentation Model which separates t