- Forum
- General C++ Programming
- How to make a design
How to make a design
I have to make an application that simulates a logical circuit. It will be one big system made up of modules, which are themselves made up of various logical gates.
The application will naturally allow the user to enter inputs for every gate, choose which modules to exclude from the system, describe the relations between modules and gates and finally, give two options of running (final system output or step-by-step output that shows current active gates).
The application will have a graphical interface in FLTK if you were thinking this was weird for a console application(which it would be), with buttons that allow for activating/deactivating sections of the circuit.
With that being said, my problem is that I don't know where to begin with the design part. I don't have much experience in designing an OOP project in c++.
Can someone explain to me what my interface should look like? I'll do the implementation myself, but I can't quite start without a good plan.
So far, I've thought of making an abstract class Gate, with each type as derivatives(AND, XOR, etc), having bool values for inputs and output and of course some setters for the inputs and a getter for the output. But that's as far as I went. I don't know how the modules or anything else would fit in.
Basically, I need a skeleton of what my header file should look like, or at the least, a detailed explanation of how I should break this project into manageable parts.
Thanks.
The application will naturally allow the user to enter inputs for every gate, choose which modules to exclude from the system, describe the relations between modules and gates and finally, give two options of running (final system output or step-by-step output that shows current active gates).
The application will have a graphical interface in FLTK if you were thinking this was weird for a console application(which it would be), with buttons that allow for activating/deactivating sections of the circuit.
With that being said, my problem is that I don't know where to begin with the design part. I don't have much experience in designing an OOP project in c++.
Can someone explain to me what my interface should look like? I'll do the implementation myself, but I can't quite start without a good plan.
So far, I've thought of making an abstract class Gate, with each type as derivatives(AND, XOR, etc), having bool values for inputs and output and of course some setters for the inputs and a getter for the output. But that's as far as I went. I don't know how the modules or anything else would fit in.
Basically, I need a skeleton of what my header file should look like, or at the least, a detailed explanation of how I should break this project into manageable parts.
Thanks.
Don't let "OOP" get in the way; think about the data first.
(OOP just means that your data know how to do things -- and that'll come automatically when you create your classes.)
Every circuit has some n number of connectors.
Each connector has characteristics: current in/out, potential, etc.
A circuit may be composed of two (or more) other circuits. Therefore, a circuit should
also maintain a list of connections and a list of those subordinate circuits.
A circuit should also know how to draw itself on an argument canvas, and to compute the current/potentials/etc across its subordinates.
The main controller should then have a canvas, a main general-purpose circuit, and a UI that can manipulate that circuit's parts.
My (possibly egregiously wrong) $0.02.
(OOP just means that your data know how to do things -- and that'll come automatically when you create your classes.)
Every circuit has some n number of connectors.
Each connector has characteristics: current in/out, potential, etc.
A circuit may be composed of two (or more) other circuits. Therefore, a circuit should
also maintain a list of connections and a list of those subordinate circuits.
A circuit should also know how to draw itself on an argument canvas, and to compute the current/potentials/etc across its subordinates.
The main controller should then have a canvas, a main general-purpose circuit, and a UI that can manipulate that circuit's parts.
My (possibly egregiously wrong) $0.02.
+-------------------------------------------------------+---------------+ | | tools palette | | ......................... | | | : : +------+ | | | : R=2 R=3 : | | | | | +--o---/\/\/---o---/\/\/---o----+ ....o.o..o.o.... | | | | : resistor resistor : : | | | | : | | | | :.......................: : AND AND : | | | | circuit 1 : | | : | | | | :....o....o....: | | | | V=12 | circuit 2 | | | | +| - | | | | +-------o---| |---o---------------------+ | | | | | | | battery | | | | | +-------------------------------------------------------+---------------+ |
closed account (48T7M4Gy)
As a rough outline.
Circuits are made up of components and connections. So therefore there are primarily three objects - classes
The Circuit Class - with at least a configuration attribute to arrange the components, a drawing method, and an analysis method.
The Component Class would have methods and attributes (no surprise there). A primary attribute would be connections to cover inputs and outputs, and methods converting the input to the output.
The Connection Class would have a start and an end point, current, voltage etc depending on the physical attributes (methods) required.
The Component and Connection classes would possible draw themselves by inheriting a draw method from the Circuit Class.
Circuits are made up of components and connections. So therefore there are primarily three objects - classes
The Circuit Class - with at least a configuration attribute to arrange the components, a drawing method, and an analysis method.
The Component Class would have methods and attributes (no surprise there). A primary attribute would be connections to cover inputs and outputs, and methods converting the input to the output.
The Connection Class would have a start and an end point, current, voltage etc depending on the physical attributes (methods) required.
The Component and Connection classes would possible draw themselves by inheriting a draw method from the Circuit Class.
Topic archived. No new replies allowed.