If I find myself defining a Component class and a ComponentInstance class, am I doing something wrong?

Question

I am trying to write a program for designing electrical circuits in C++. At run-time, the user will be able to create a new type of component and will define its various attributes (e.g. number of pins, names of pins). They will then be able to create a circuit which includes multiple instances of these various user-created component types. When I tried to code this, I initially created a Component class, which would represent a type of component and store its number of pins, pin names, etc., as well as a ComponentInstance class to represent an instance of this component as part of a circuit. The ComponentIntance class maintains a reference back to its Component so that any changes to the Component will be reflected in its instances.
When I sat down and thought about my code, this seemed a bit clumsy. I am using an object-oriented language which provides facilities for exactly this kind of relationship: classes to represent a type and objects to represent an instance. The issue that I am having is that I don't know how to take advantage of these facilities because the type relies on user-provided input. Additionally, the user should be able to change the properties of the type and have these changes reflected in existing instances.
I thought that perhaps I should use some sort of template trickery to create this system, but I don't know if this is the right method, and even if it is, I don't know how to actually implement it. Any assistance would be greatly appreciated.

Answer 1

From what you said below:

Additionally, the user should be able to change the properties of the type and have these changes reflected in existing instances.

It seem the user can change the properties at run time. If so, then template parameters won't be useful for these properties, since they must be determined and fixed at compile time.

I have seen similar problems when working on a specialized EDA library. Because the EDA library needs to do design exploration at run time, the properties of circuit elements cannot be fixed at compile time of the library. We ended up creating one class for each basic type of elements: one for registers, one for muxes, one for buffers, one for buses and signals, etc. Each class contains the following data members:

• A basic type identifier as static const std::string typeName;
• An element identifier as const std::string elementName;
• Member objects for inputs, outputs, clocks, memories, etc., as std::vector's and/or std::map's

Two instances of the same class should always have different elementName's. They have the same circuit properties if and only if they have the same member object sizes.

In our case, the user couldn't/wouldn't change properties of all elements of some property to a different property (such as changing all 32-bit registers to 64-bit wide). If this is what you want, perhaps a mapping from the property setting to the set of circuit elements with that setting could be used:

std::map<std::pair<"register", 32>,
         std::set<Register> > register32_elements;

If there are N Register elements of 32 bits, the complexity to change all of them to 64 bits will be O(N). But we'd need to update each individual register anyway. This may be an alternative that creates fewer number of C++ classes (and probably lines of code) than your approach.

Hope this helps...