Hi

So, I have the following problem:

I have to store several types of Cells, (call them A, B, ...), where the
number of Cell types is going to increase as we continue development.

Among other things, I have to compute inductances between all
combinations of these cells. How the inductance is computed depends
entirely on the type of cell.

It seems like there must be an elegant solution to this, probably a
design pattern. The naive solutions I think of have big disadvantages:
If I store a pointer of base classes, calculating the inductances gets
messy and complicated (especially as the number of Cell types
increases). If I store the different cell types seperately, the routines
where I calculate over the different combinations of cells gets ugly, and
scales badly.

So can someone give me a good idea, point me at a good pattern, whatever?

Thanks,

Glen

gas wrote:
> I have to store several types of Cells, (call them A, B, ...), where the
> number of Cell types is going to increase as we continue development.

Are they different types or different "types"? What's the actual
difference? Do you model the difference in behaviour using virtual
functions (polymorphism) or using some kind of property data and an
internal switch statement[s]?

> Among other things, I have to compute inductances between all
> combinations of these cells. How the inductance is computed depends
> entirely on the type of cell.

So, the computation mechanism will have to either know what type of cell
(the true type) it is (by querying the property data) or require the
cell itself to perform part of the computation thus relying on cells'
polymorphic behaviour, right?

> It seems like there must be an elegant solution to this, probably a
> design pattern.

Looks like a Visitor pattern...

> The naive solutions I think of have big disadvantages:
> If I store a pointer of base classes, calculating the inductances gets
> messy and complicated (especially as the number of Cell types
> increases). If I store the different cell types seperately, the routines
> where I calculate over the different combinations of cells gets ugly, and
> scales badly.
>
> So can someone give me a good idea, point me at a good pattern, whatever?

You seem to be in the OOD land here and yours is not really a C++
language problem. Try posting your inquiry to 'comp.object'. There is
also 'comp.software.patterns' newsgroup which might be worth visiting.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Wed, 16 Jul 2008 13:57:37 -0400, Victor Bazarov wrote:

Thanks for the reply.

> gas wrote:
>> I have to store several types of Cells, (call them A, B, ...), where
>> the number of Cell types is going to increase as we continue
>> development.
>
> Are they different types or different "types"? What's the actual
> difference? Do you model the difference in behaviour using virtual
> functions (polymorphism) or using some kind of property data and an
> internal switch statement[s]?

I was trying to avoid details and boil the question down to just the
relevant information, but maybe I boiled it too much. To give the
context, I've been brought in to work on a project that has been
developed, until now, primarily by students. The application models
electromagnetic behavior of circuit elements. Thus far, inductances have
been calculated solely by approximating the elements of Bars (Bars is an
eponymous class), or series of Bars . Now we would like to extend our
approximations to contain also Cylinders, hollow cylinders, etc. To save
on typing I shortened these to A,B,C, etc... So they are different
classes.

Polymorphism is useful to our program design, but not in the context I am
discussing here. Vis:

>> Among other things, I have to compute inductances between all
>> combinations of these cells. How the inductance is computed depends
>> entirely on the type of cell.
>
> So, the computation mechanism will have to either know what type of cell
> (the true type) it is (by querying the property data) or require the
> cell itself to perform part of the computation thus relying on cells'
> polymorphic behaviour, right?

It cannot rely on the cells polymorphic behavior. If it did, that would
certainly make the issue simple, and I wouldn't be posting here. The
integrals which have to be performed depend on the combination of
elements. So there is totally different behavior for calc_ind(A,A),
calc_ind(A,B), calc_ind(B,B), and so on. Querying types and using
switches is certainly a solution but, as I mentioned in the original
post, has obvious disadvantages in scaling.

Ideally, I would use overloaded functions to implement the routines, but
then the code where I iterate over all combinations of elements gets
pretty ugly, and hard to extend.

>> It seems like there must be an elegant solution to this, probably a
>> design pattern.
>
> Looks like a Visitor pattern...

I have to admit a low familiarity with design patterns. I thought the
visitor class was relevant to visiting single classes, not pairs of
classes. Thanks for the tip, I'll go have a read now.

> > The naive solutions I think of have big disadvantages:
>> If I store a pointer of base classes, calculating the inductances gets
>> messy and complicated (especially as the number of Cell types
>> increases). If I store the different cell types seperately, the
>> routines where I calculate over the different combinations of cells
>> gets ugly, and scales badly.
>>
>> So can someone give me a good idea, point me at a good pattern,
>> whatever?
>
> You seem to be in the OOD land here and yours is not really a C++
> language problem. Try posting your inquiry to 'comp.object'. There is
> also 'comp.software.patterns' newsgroup which might be worth visiting.

Well, the code is in C++. I don't care if the best solution stems from
an OO paradigm, a generic paradigm, a functional programming paradigm, or
a combination thereof, as long as I can implement in C++.

Thanks for your time.

gas <gas@notmyrealmail.com> writes:
>So there is totally different behavior for calc_ind(A,A),
>calc_ind(A,B), calc_ind(B,B), and so on.

Such behavior is written using so-called »multimethods«, here
»bimethods« (my term for multimethods with two parameters).

The visitor pattern mentioned is a means to emulate bimethods
in languages without multimethods.

http://google.to/search?q=multimethods+C%2B%2B

This is needed only, if the types are only known at run-time.
If the types are known at compile time, you just can overload
calc_ind.