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.
