Un seguito di un'altra domanda ( Prendere una decisione progettuale sulla lettura dei dati del modello da un file di input ).
Desidero fare un'altra domanda riguardante il costruttore o il modello di fabbrica. (Ho letto che il builder è più complesso di fabbrica, e per il momento non ho bisogno di usare builder). Quindi ecco i dati che devo leggere:
TABLE: "DEGREES OF FREEDOM"
X=Yes Y=Yes Z=Yes R1=Yes R2=Yes R3=Yes
TABLE: "ANALYSIS OPTIONS"
Solver=Advanced SolverProc=Advanced
TABLE: "COORDINATE SYSTEMS"
Name=GLOBAL Type=Cartesian X=0 Y=0 Z=0
TABLE: "GRID LINES"
CoordSys=GLOBAL AxisDir=X GridID=A XRYZCoord=-720 LineColor=Gray8Dark Visible=Yes
CoordSys=GLOBAL AxisDir=X GridID=B XRYZCoord=-432 LineColor=Gray8Dark Visible=Yes
CoordSys=GLOBAL AxisDir=X GridID=C XRYZCoord=-144 LineColor=Gray8Dark Visible=Yes
CoordSys=GLOBAL AxisDir=X GridID=D XRYZCoord=144 LineColor=Gray8Dark Visible=Yes
CoordSys=GLOBAL AxisDir=X GridID=E XRYZCoord=432 LineColor=Gray8Dark Visible=Yes
CoordSys=GLOBAL AxisDir=X GridID=F XRYZCoord=720 LineColor=Gray8Dark Visible=Yes
...
Ci sono molte altre tabelle come queste. Alcune tabelle hanno relazioni padre-figlio (ogni sistema di coordinate ha una propria griglia). Ho creato delle strutture che rappresentano ciascuna tabella, in questo modo:
struct ActiveDOF
{
bool Ux;
bool Uy;
bool Uz;
bool Rx;
bool Ry;
bool Rz;
};
struct GridLine
{
enum Direction{X, Y, Z};
enum Type{PRIMARY, SECONDARY};
enum Location{START, END};
std::string coodSystem;
Direction direction;
std::string gridID;
float XRYZ;
Type lineType;
QColor color;
bool visible;
Location bubleLoc;
bool allVisible;
float bubleSize;
};
struct CoordinateSystem
{
std::string name;
std::string type;
QVector3D center; // center x, center y, cetner z
QVector3D about; // aboutx, about y, about z
std::vector<GridLine> gridLines;
};
queste strutture di dati sono incorporate nella classe del modello, che costituirà una classe enorme poiché ci sono 50 strutture di dati dispari come questa:
class Model
{
private:
ActiveDOF activeDOF;
CoordinateSystem coordinateSystem;
....
public:
Model() {} ...
}
ogni tabella deve avere il suo metodo set e ottenere il metodo. Questo design mi preoccupa perché se decido di cambiarlo, sarà molto dispendioso in termini di tempo. Apprezzo qualsiasi suggerimento. Penso che anche qui le informazioni metteranno la domanda precedente in una luce migliore.
Ora, non so dove dovrebbe andare il builder o il metodo factory, data la situazione. Ho esaminato alcuni grafici di codice e UML, ma non sono stato in grado di capire come implementare la fabbrica o il costruttore per creare le strutture necessarie per il mio progetto. Devo avere accesso a ciascun tavolo per nome, perché potrebbero essere soggetti a modifiche all'interno del modello, quindi per il momento sto evitando di fare di ognuno di essi una sottoclasse di una classe base virtuale, in modo che possa memorizzarli in un contenitore.
Inoltre, ha senso che invece di dichiarare un'istanza della struttura dei dati, dovrei tenere un puntatore a loro? se tutte le strutture dati derivano da una classe base virtuale chiamata Record, il modello sarà simile al seguente:
class Model
{
private:
ActiveDOF* activeDOF;
CoordinateSystem* coordinateSystem;
....
std::Vector<Record*> data;
public:
Model() {} ...
}
Penso che sia un lavoro extra da allocare, dislocare la memoria per loro, ma può aiutare a gestire i dati e mantenere la digitazione in più? ho ragione nell'assumerlo?