[Corelinux-public] Functional Requirement 2872 - Adapter Pattern

[Frank V. C. <fr...@co...>]

Title         : Adapter Pattern
Requirement ID: 2872

1. Introduction

Design Patterns (Gamma et al) page 139

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 became 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.5 Foreseeable Non-Functional Changes

NA

4. Remarks and Guidelines for Later Life Cycle Phases

TBD

5. Term Glossary 

TBD

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux