web-dev-qa-db-fra.com

Motif d'usine ou modèle de constructeur? Lequel convient-il à la lecture des données de modèle finis des éléments d'un fichier texte?

Un suivi à une autre question ( prise de décision de conception concernant la lecture des données du modèle à partir d'un fichier d'entrée ).

Je souhaite poser une autre question concernant le constructeur ou le modèle d'usine. (J'ai lu que ce constructeur est plus complexe que l'usine et je n'ai peut-être pas besoin d'utiliser le constructeur pour le moment). Voici donc les données que je dois lire:

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   
   ...

Il y a beaucoup plus de tables comme celles-ci. Certaines tables ont des parents, les relations entre enfants (chaque système de coordonnées contient une ligne de réseau. J'ai fabriqué des structures qui représentent chaque table, comme ceci:

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;
};

ces structures de données sont intégrées à la classe modèle, qui fera une classe énorme car il y a 50 structures de données impaires telles que ceci:

class Model
{
private:
ActiveDOF activeDOF;
CoordinateSystem coordinateSystem;
....

public:
Model() {} ...

}

chaque table doit avoir sa méthode définie et obtenir la méthode. Cette conception m'inquiète parce que si je décide de le changer, il va y avoir beaucoup de temps. J'apprécie toute suggestion. Je pense que les informations ici mettront également la question précédente dans une meilleure lumière.

Maintenant, je ne sais pas où la méthode de constructeur ou d'usine devrait aller, étant donné la situation. J'ai examiné certains graphiques de code et UML, mais je n'ai pas pu comprendre comment mettre en œuvre l'usine ou le constructeur de créer des structures nécessaires à ma conception. Je dois avoir accès à chaque table par son nom, car ils pourraient être soumis à des changements à l'intérieur du modèle, alors pour le moment, j'évite la fabrication de chacune d'elles une sous-classe d'une classe de base virtuelle, de sorte que je puisse les stocker dans un récipient.

En outre, a-t-il de sens que, au lieu de déclarer une instance de la structure de données, je devrais garder un pointeur pour eux? Si toutes les structures de données sont dérivées d'une classe de base virtuelle appelée enregistrement, le modèle sera comme ceci:

class Model
{
private:
ActiveDOF* activeDOF;
CoordinateSystem* coordinateSystem;
....

std::Vector<Record*> data;

public:
Model() {} ...

}

Je pense que c'est un travail supplémentaire pour allouer, disloquer la mémoire pour eux, mais cela peut aider à gérer les données et à garder une dactylographie supplémentaire? Ai-je raison de supposer ça?

designc++classrelationships
3
Ring Zero.

Un constructeur serait "construit" dans un invarient d'usine (méthode), afin de lire un fichier texte, vous écririez 1 usine avec une méthode pour lire ledit fichier. Maintenant, si vous devez construire progressivement votre modèle à partir des données que vous avez lues (réfléchissez à des données imbriquées), le modèle de constructeur à l'intérieur de la méthode d'usine vous servirait bien. Cependant, un seul modèle suffira probablement de charger vos données.

0
RandomUs1r

Compte tenu de la taille et de la complexité de votre structure, un constructeur semble plus approprié, surtout si votre modèle est (ou peut être fait) immuable. Vous devrez accepter un couplage serré entre le constructeur et le modèle, mais cela vaut la peine, surtout si vous aurez besoin de construire des modèles à plusieurs endroits. Un constructeur vous permet également d'encapsuler la validation.

Toutefois, si votre modèle est mutable et que ce n'est créé que dans le même endroit, une usine peut être plus appropriée et plus appropriée et Yagni entre en jeu.

En réponse à votre autre question, vous ne devez jamais stocker les pointeurs bruts en C++. Le fait est std::unique_ptr n'a pas d'aphteurs et cela informe la destruction des objets. Lorsque ce vecteur sort hors de portée, il ne libérera pas la mémoire qu'elle références comme-écrite, mais avec un document_ptr, cela le ferait.

Je créerais un vecteur pour de grandes quantités d'éléments répétés, en particulier si la quantité est susceptible de changer, mais pour les composants de taille moyenne jamais partagés, vous pourriez aussi bien les inclure directement dans la structure.

0
Alex Reinking