Boost logo

Boost :

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-03-07 16:52:56

In message <7D72C1B2F7A3D21191F8006097149AC0A89D98_at_[hidden]>,
Borgerding, Mark A. <MarkAB_at_[hidden]> writes
>> Based on work I did in the past, you may also wish to
>> consider breaking
>> the means up: the media (eg file, socket) and the representation (eg
>> native binary, text, CDR). This allowed the representation to
>> be treated
>> as orthogonal to the media mechanism.
>I like this idea. A sort of traits class for the representation. I think
>that it might be best implemented at the level of subclass of
>PersistenceMeans, since the data object should not really care about
>anything except how to describe its structure to the abstract
>PersistenceMeans interface. Another reason to implement it at this level is
>because some persistence means may not have options when it comes to
>representation. For a database, the representation is dictated by the table
>layout. For text files, the representation may be limited to printable

This approach was considered but rejected in the framework I worked on,
as it was felt that it would lead to code duplication and reduced
flexibility: files, sockets, BLOB fields, etc can handle text and
binary. YMMV w/ the kind of system you are developing. The tradeoff is
that it pushed some validity checks out until runtime. There are a
number of approaches, including a visitor-like strategy, or strict
creation through factories/builders, such that only legal combinations
are constructed.

>I must admit that the adapter functionality rarely got used, even though it
>was in the framework from the start and fairly well documented.

Yes, you don't want to end up gold plating for eventualities that never
arise, but OTOH working outside the imposition of an inheritance
structure is a common need for some frameworks/mindsets.

  Kevlin Henney Without art we are nothing
  kevlin_at_[hidden] but monkeys with car keys

Boost list run by bdawes at, gregod at, cpdaniel at, john at