CoreLinux++ Functional Requirement Document
Revision $Revision: 1.2 $
Last Modified : Sunday, January 9, 2000

Title : Adapter Pattern

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

1. Introduction

An Adapter converts the interface of a class into another interface that clients expect. This allows classes work together that couldn't otherwise because of the incompatible interfaces. Sometimes a toolkit class that's designed for reuse isn't reusable only because its interface doesn't match the domain specific interface an application requires.

1.1 Deliverables Overview

In review of some of the requirements for libcorelinux++ and applying some foresight, it is apparent that there will be times when either the library, framework, or user extensions will want to use the implementation of other class libraries without loosing the type relationships in libcorelinux++.

For example, if we state that in some class requirement there is a need for a String, but as application needs change a particular case wants to use a UCS2 string or UCS4 string then any of our core classes that had a dependency on a UTF8 string would potentially break. With an Adapter class we could have our core classes use a base or Abstract string and provide Adapaters that maintain the interface our core objects would expect (through delegation).

This deliverable is very light weight in that we want to capture the Adapter type class and not much more at this point.

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

Users can use this as a basis for creating their own Adapter hierarchies outside of the libcorelinux++ library.

2. Functional Requirements

Adapter will be publically available for extension.

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 factoring of some method or data member that is recognized across many domains, in other words not likely.

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