Egy másik kérdés nyomon követése ( Tervezési döntés meghozatala a modelladatok beolvasási fájlból történő olvasásáról ).
Szeretnék még egy kérdést feltenni az építővel vagy a gyári mintával kapcsolatban. (Azt olvastam, hogy az építő bonyolultabb, mint a gyár, és lehet, hogy egyelőre nem kell használnom az építőt). Tehát itt vannak az adatok, amelyeket el kell olvasnom:
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 ... Még sok ilyen táblázat található. Egyes táblázatokban van szülő, gyermek kapcsolat (mindegyik koordináta-rendszernek saját rácsvonala van). Olyan struktúrákat készítettem, amelyek az egyes táblákat reprezentálják, így:
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; }; ezek az adatstruktúrák beépülnek a modellosztályba, amely hatalmas osztályt fog alkotni, mivel vannak 50 ilyen páratlan adatstruktúra:
class Model { private: ActiveDOF activeDOF; CoordinateSystem coordinateSystem; .... public: Model() {} ... } minden táblának meg kell adnia a beállított és a get metódust. Ez a kialakítás aggaszt, mert ha úgy döntök, hogy megváltoztatom, akkor nagyon időigényes lesz. Nagyra értékelem minden javaslatot. Úgy gondolom, hogy az itt szereplő információk is jobban megvilágítják a korábbi kérdést.
Most már nem tudom, hogy az építő vagy a gyári módszer hová menjen, figyelembe véve a helyzetet. Megnéztem néhány kódot és UML táblázatot, de nem tudtam megérteni, hogyan kell megvalósítani a gyárat vagy az építőt minden egyes táblához név szerint kell hozzáférnem, mert lehet, hogy a modellen belül változhatnak, ezért egyelőre kerülöm, hogy mindegyiket egy virtuális alaposztály alosztályává tegyem, hogy tárolhassam őket egy tárolóban.
Ezenkívül van értelme annak, hogy az adatstruktúra egy példányának deklarálása helyett tartanom kell egy mutatót hozzájuk? Ha az összes adatstruktúra egy a Record nevű virtuális alaposztály, akkor a modell valami ilyesmi lesz:
class Model { private: ActiveDOF* activeDOF; CoordinateSystem* coordinateSystem; .... std::Vector<Record*> data; public: Model() {} ... } Szerintem többletmunka a memória lefoglalása, elmozdítása számukra, de ez segíthet az adatok kezelésében és az extra gépelésben? Igazam van ezt feltételezve?
Megjegyzések
Válasz
Megpróbál megoldani egy adatelérési problémát, és ez adatelérési megoldást igényel.
Először vizsgáljuk meg a javasolt megoldásokat, és azt, hogy miért nem oldják meg a problémákat.
A gyári minta
A gyári tervezési minta (más néven gyári módszer minta) akkor hasznos, ha a polimorfizmust akarja hasznosítani, és az objektumok felépítését teljesen el akarja különíteni a megvalósítási osztályoktól.
Osztályalapú programozásban a gyári metódus egy olyan kreatív minta, , amely gyári módszerekkel kezeli az objektumok létrehozásának problémáját anélkül, hogy meg kellene adnia a a létrehozandó objektum pontos osztálya. Ez úgy történik, hogy objektumokat hoz létre egy gyári metódus meghívásával — egy interfész, amelyet gyermekosztályok valósítanak meg, vagy alaposztályban valósítanak meg, és adott esetben felülírják a — származtatott osztályok helyett, ha konstruktort hívnak meg .
(kiemelés, az enyém)
És tovább részletezi a minta által megoldott problémák:
A Factory Method tervezési minta megoldja a következő problémákat:
- Hogyan hozható létre objektum hogy alosztályok újra meghatározhassák, melyik osztályt példányosítsák?
- Hogyan halaszthatja el egy osztály a divissziót alosztályokba?
A kérdésedben leírt problémák különböznek ettől. Ön nem foglalkozik alosztályokkal vagy polimorfizmussal. A gyári minta nem megoldás.
Az építőminta
Az építőminta ( Wikipédiából ):
A Builder egy tervezési minta, amelyet arra terveztek, hogy rugalmas megoldást kínáljon az objektum-orientált programozásban az objektumok létrehozásának különböző problémáira. A Builder tervezési minta célja egy összetett objektum felépítésének elkülönítése az ábrázolástól.
(kiemelés, az enyém)
Itt is ismét eltérést tapasztalunk az Ön által leírt probléma és a minta rendeltetése között.
A Builder tervezési minta olyan problémákat old meg, mint:
- Hogyan hozhat létre egy osztály (ugyanaz az építési folyamat) a komplex objektum ?
- Hogyan lehet egy osztály, amely magában foglal egy összetett objektum leegyszerűsödik?
(hangsúly, az enyém)
A kulcs itt egy objektum (objektum = 1 objektum) felépítése bonyolult. Ennek oka lehet sok konstruktor-argumentum, vagy annak függőségeinek összeállítása.
Egyénileg mindegyik struktúra vagy osztály meglehetősen egyszerű, így az építőminta sem felel meg jól.
Adathozzáférési minták (A megoldás)
Azok a problémák, amelyeket valójában megpróbál megoldani, az adatokhoz való hozzáférés végrehajtása, és lehet, hogy egy Adathozzáférési objektum .
Számítógépes szoftverben egy adatelérési objektum (DAO) olyan objektum, amely elvont felületet biztosít valamilyen típusú adatbázishoz vagy más perzisztencia mechanizmushoz. Az alkalmazáshívások leképezésével a perzisztencia réteghez , a DAO bizonyos adatműveleteket végez az adatbázis részleteinek feltárása nélkül.
Az Ön esetében cserélje le az “adatbázis” szót a “szövegfájl” kifejezésre. A kapcsolódó tervezési minta a Repository Design Pattern , amely három fő megoldásra bontja az adatokhoz való hozzáférést:
- Repository — az “adatelérési dolgok” nyilvános felülete
- Az átjáró — tudja, hogyan kell beszélni egy Oracle adatbázissal, vagy hogyan kell olvasni / írni szöveges fájl. Ez magában foglalja az objektumok és a struktúrák sorosítását az SQL-re vagy a szövegfájlban elvárt adatformátumra.
- A gyár — az átjáró által visszaküldött adatokat hozzárendeli az objektumokhoz és a struktúrákhoz. az alkalmazás többi része használja
A memória tulajdonjoga
Mivel nincs előnye / korlátja a memória automatikus kezelésének, ezért a memória tulajdonosa ezek az objektumok és struktúrák mindenképpen aggodalomra adnak okot. Itt döntést kell hoznia:
- Az adatelérési objektum felelős e memória megtisztításáért?
- Az adatelérési objektum elvárhatja, hogy a hívó (ügyfélkód) vállaljon felelősséget ennek a memóriának a felszabadításáért?
Ha az adatelérési objektum az alkalmazás indításakor jön létre, és az alkalmazás leállításáig él, akkor az adatokhoz való hozzáférés Az objektum tulajdonosa lehet ennek a memóriának.
Ha az adatelérési objektumot igény szerint hozzák létre, majd ártalmatlanítják, az ügyfélkódnak meg kell győződnie arról, hogy a memória nem tiszta ned.
Határozza meg ezt az adatelérési objektum megjegyzéseiben vagy dokumentációjában, és érvényesítse ezt a kódellenőrzés során.
Megjegyzések
- tetszik ez a megközelítés. Sokkal rugalmasabban néz ki. Bármi más, amit kérek, rávilágít a tudatlanságomra az ügyben. Magam hajtsam végre a DAO-t? Ahogy értem, meg kellene írnom a Gateway and Factory-t? Az Átjáró megegyezik a híd GOF mintájával?
- Azt mondanám, hogy az átjáró a lerakati mintában a hídminta másik változata. Valójában úgy tűnik, hogy a tárház mintázatának alapja egy szervezettebb és összehangoltabb hídminta, amely kifejezetten az adatelérésre összpontosít. És igen, valószínűleg ‘ valószínűleg magának kell megírnia ezeket az összetevőket.
- az Ön által közzétett linkeket követve eljutottam a következőhöz: hu.wikipedia.org/wiki/ODB_(C%2B%2B) , Hogyan illik a képbe ez az ODB? Írhatok programot a szövegbevitel sqllite-be konvertálására, majd az ODB-t használhatom kitartásra? ez a hang? Azt kell mondanom, hogy csak megbotlottam az ODB-ben, és két példát néztem, így ez nem megalapozott megjegyzés.
- A kódíráshoz nyújtott segítség nem tartozik a témára ezen a webhelyen, azonban ‘ biztos vagyok benne, hogy a szöveget sqlite-be konvertálhatja, és egy meglévő könyvtárat használhat.
Válasz
A gyári invariáns (metódus) belsejében építene egy “építőt”, amely szöveges fájlt olvasna, írsz 1 gyárat egy módszerrel az említett fájl olvasására. Most, ha fokozatosan kell felépítenie a modelljét az elolvasott adatokból (gondoljon beágyazott adatokra), a gyári módszeren belüli készítő minta jól szolgálna. Valószínűleg azonban egyetlen modell elegendő az adatok betöltéséhez.
Megjegyzések
- Egyes álkódok nagyon hasznosak lehetnek. Még soha nem használtam gyári vagy készítő mintákat.
Válasz
Tekintettel a szerkezet méretére és összetettségére, egy építő tűnik a legmegfelelőbbnek, különösen, ha a modellje megváltoztathatatlan (vagy elkészíthető). El kell fogadnia a szoros összekapcsolást az építő és a modell között, de megéri a fáradságot, különösen, ha több helyre kell modelleket építenie. Az építő lehetővé teszi az érvényesítés beillesztését is.
Ha azonban a modelled változtatható, és csak egy helyen készül, akkor egy gyár megfelelőbb és célszerűbb lehet, és a YAGNI is szerepet játszik.
Válaszul a másik kérdésedre , soha nem szabad tárolnia a nyers mutatókat a C ++ nyelven. A tény: std::unique_ptr nincs hátránya, és elbagatellizálja az objektum pusztulását. Amikor ez a vektor kijön a hatókörből, nem szabadítja fel a memóriát a hivatkozások írott formában, de egyedi_ptr esetén igen.
Vektort hoznék létre nagy mennyiségű ismétlődő elemhez, különösen, ha a mennyiség valószínűleg változni fog, de a közepes méretű, soha nem megosztott komponensek esetén ezeket is felveheti közvetlenül a struktúrába.
Modelosztály különböző levezetései vannak a különböző alaposztály különböző levezetéseiModelBasevagyIModel), és központosítani kívánja a döntést arról, hogy melyik konkrét levezetés válik példányossá. Nem ‘ nem látom ezt a problémát a kérdésében, akkor mi az a ‘ elképzelése, hogy itt gyárat használ?