CoreLinux++ Functional Requirement Document
Revision $Revision: 1.2 $
Last Modified : Wednesday, January 19, 2000

Title : Bridge Pattern

Requirement ID: 3142
Analysis References: Use Case Report , Analysis Diagrams
Design References: Class Report, Design Diagrams
Cross References:

1. Introduction

When an abstraction can have one of several possible implementations, the usual way to accommodate them is to use inheritance. An abstract class defines the interface to the abstraction, and concrete subclasses implement it in different ways. But this approach isn't always flexible enough. Inheritance binds an implementation to the abstraction permanently, which makes it difficult to modify, extend, and reuse abstractions and implementations independently. A Bridge decouples an abstraction from its implementation so that the two can vary independently.

1.1 Deliverables Overview

In a typical Bridge use case, the developer will have a Bridge implementation associated to an abstraction, where all operations on the abstraction subclass are implemented in terms of abstract operations from the Bridge abstraction. Other implementations have utilized or made reference to the Bridge pattern for copy on write behavior. I believe that the std::bastring template implementation of g++ uses this.

The deliverable is mostly vacuous in that we want to capture the Bridge type class and not much more at this point.

The CoreLinux++ team will deliver Bridge implementations for specific cases as needed.

Users can utilize this as a basis for creating their own Bridge implementation hierarchies outside of the libcorelinux++ library.

2. Functional Requirements

Bridge will be publicly available for extension.

Bridge shall be flexible in regards to type of the Implementation object.

2.1 User Interface Specifications

NA

2.2 Product Services

NA

2.3 External Interfaces and Database Requirements

NA

2.4 Error Handling

NA

2.5 Foreseeable Functional Changes and Enhancements

At this level, the only consideration may be the immediate extension of the base Bridge abstraction to include one that has reference counting behavior.

3. Non-Functional Requirements

Precondition constraints: None

Postcondition constraints: None

Invarient constraints: None

3.1 Performance Requirements

NA

3.2 User Documentation and Other User Aids

This Document

Analysis Use-Case diagrams

Design class diagrams

3.3 Development Requirements

Standards: CoreLinux++ C++ Standards and Guidelines

Will be part of the libcorelinux++ shared library.

3.4 Foreseeable Non-Functional Changes

NA

4. Remarks and Guidelines for Later Life Cycle Phases

TBD

5. Term Glossary

TBD