C++ framework design question

[Angus]

Hello

I am creating a C++ framework for working with telephone systems.
There are a lot of different interfaces and this is the main problem.

Currently my basic design is as follows:

Abstract factory pattern. Creates a telephony object without
specifying concrete classes.

The telephony object then creates a interface class (IFace) which has
supporting device and call classes. The IFACE class has a list of the
calls and devices. Devices are for example a telephone handset.

The IFace, device and call objects are abstract. Then I have these
sort of interfaces for actual implementation:

class ABCPhone: public IFace

class ABCDevice : public device

class ABCCall : public call

Currently I am working on two actual implementations - lets call them
ABC and XYX.

When I created the ABC implementation I would create for example ABC
devices and calls and put a lot of the device and call processing code
in IFace, device and call. This has the advantage that anything in
the abstract classes can be re-used. But the problem is that now I am
developing XYZ interface, the standard code in these abstract classes
needs to be extended to cope with the peculiarities of XYZ.
Unfortunately XYZ is quite different to ABC.

So I am re-writing a lot of the code originally in IFace, device and
call into ABCPhone, ABCDevice and ABCCall. That is fine but means I
will have quite a lot of specific code for each implementation (longer
development cycles).

For example, is it a good idea to have a list of eg call objects in
the IFace class? If I need to extend call for specific
implementations then I need a list of XYZCalls for example? Then no
need for a list of call's?

Any tips on how to design this would be much appreciated.

A

 

[Grizlyk]

For example, is it a good idea to have a list of eg call objects in
the IFace class?  If I need to extend call for specific
implementations then I need a list of XYZCalls for example?  Then no
need for a list of call's?

As for me, i do not understand what you want: "who" calls "what" and
"why". But with your other question:

On Jan 3, 8:31 pm, Angus wrote:

To interface with an actual device the framework user would extend
devices like this:

class ABCDevice : public devices

i try to guess, you are speaking about casting to derived "ABCDevice"
from base class "devices", are not?

Well, OO designed program is a way to refuse from IOCTL-like access to
devices, but i want to warn you about OO properties of C++.

Very short answer.
------------------

If you have a ready, desined and tested OO project, you can try to
implement the project with the help of C++, otherwise you will get
many problems only.

And what to do?

I have tried to apply in work existed OO properties of C++ and found,
that if you want to get any practical useful result, that than simpler
OO actions you will use with C++, than better will be result.

Really, you can make safe only some:
- classes as ADT (or ATD), often as "freestanding";
- templates, that are able to work with the classes;
- patterns to deal with the classes and templates;
and after that do not dream, just make you program according to
functional paradigm with the ADT, templates and patterns.

You will get the "better C" - result that hardly can be reached with
pure C, but quite far from pure OO profits.

More wide answer.
-----------------

1. C++ can not represent OO source code in right manner.

It is hard to work with OO source code and users are inclined to mix
interfaces and implementation.

class T
{
....
int items()const
//wrong way!
{return _items;}

You, as user, can not represent source code as pure interface and
relations between them

class T
{
....
int items()const;

or as pure local implementation

int T::items()const {return _items;}

Smalltalk environment is a most simple example (for C++ the IDE much
more complex) of the OO source code representation:

picture here (able to work with intel 286 1M RAM about twenty ears
ago)
http://educh.chat.ru/pre/cpp/smtr.gif

2. C++ mixes declaration and implementation of abstraction.

You can not make OO program working with implementations of
abstractions directly. You will get unresolveable problems even with
desing of your application. You can try if you do not believe me.

There are differences between an pure abstraction "Idevice" and class
"Tdevice", because any class is a kind of concrete implementation
(layout in memory, for example) of an pure abstraction (the "Tdevice"
is a concrete implementaion of the "Idevice").

With classes, instead of work with your job (with logical properties
of your "devices") you will always think "how my different
implementations will work together and effectively".

When you just add to C++ the new layer of pure abstractions (assume
"interfaces") you will find set of problems with:
- relationships betwen "interfaces",
- similar relationships between implementations ("classes" an other
interface implementors *),
- relationships between "interfaces" and its implementations

(* In addition to "classes", there is other useful interface
implementors (assume "gates") )

3. C++ does not support design patterns.

Excuse me, OO language must have direct support of patterns, without
patterns, such as "adapter" or "decorator" it is not easy to work with
reusable software. There are houndreds "adapters" in many OO programs,
for C++ each of them coded by "copy&paste" design tool.

4. While it is enough.

Very short soluition.
---------------------

Note, that effective implementation of OO paradigm is still a kind of
research work (at least for me and all people i know). I think, that
it is much better to spend extra time to improve language than use
wrong equipment: "it is better to waste a day, but later to fly for
one hour".

There is offered C++ improvement as pair cC++/uC++, where item uC++
try to solve the problems . But uC++ required cC++ - special OO
language of support of uC++ compiler with portable IO layer (similar
to directX) to express uC++.

===
that all folks