Seuranta toiseen kysymykseen ( Suunnittelupäätöksen tekeminen mallitietojen lukemisesta syötetiedostosta ).
Haluan esittää toisen kysymyksen rakentajasta tai tehtaan mallista. (Luin, että rakentaja on monimutkaisempi kuin tehdas, ja minun ei ehkä tarvitse käyttää rakennustyökalua toistaiseksi). Joten tässä on luettavat tiedot:
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 ... Tällaisia taulukoita on paljon enemmän. Joissakin taulukoissa on vanhemman ja lapsen väliset suhteet (jokaisella koordinaattijärjestelmällä on oma ruudukkoviiva). Olen tehnyt rakenteita, jotka edustavat kutakin taulukkoa, näin:
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; }; nämä tietorakenteet on sisällytetty malliluokkaan, mikä tekee valtavan luokan, koska niitä on 50 tällaista parittomat tietorakennetta:
class Model { private: ActiveDOF activeDOF; CoordinateSystem coordinateSystem; .... public: Model() {} ... } jokaisella taulukolla on oltava asetettu menetelmä ja get-menetelmä. Tämä malli huolestuttaa minua, koska jos päätän muuttaa sitä, se vie paljon aikaa. Arvostan kaikkia ehdotuksia. Luulen, että myös tässä olevat tiedot asettavat aiemman kysymyksen paremmin valoon.
En tiedä, minne rakentajan tai tehtaan menetelmän pitäisi mennä tilanteen mukaan. Katsoin joitain koodi- ja UML-kaavioita, mutta en pystynyt ymmärtämään, miten tehdas tai rakentaja otetaan käyttöön Minulla on oltava pääsy jokaiseen taulukkoon nimen mukaan, koska ne saattavat muuttua mallin sisällä, joten toistaiseksi vältän tekemästä jokaisesta niistä virtuaalisen perusluokan alaluokkaa, jotta voin tallentaa ne säilöön.
Onko myös järkevää, että sen sijaan, että julistan tietorakenteen ilmentymää, minun pitäisi pitää heille osoitin? jos kaikki tietorakenteet ovat peräisin virtuaalinen perusluokka nimeltä Record, malli tulee olemaan tällainen:
class Model { private: ActiveDOF* activeDOF; CoordinateSystem* coordinateSystem; .... std::Vector<Record*> data; public: Model() {} ... } Minusta on ylimääräistä työtä jakaa muistia heille, mutta se on voi auttaa tietojen hallinnassa ja pitää ylimääräistä kirjoittamista? olenko oikeassa olettaessani sen?
Kommentit
Vastaa
Yrität ratkaista tiedonsiirto-ongelman, ja se vaatii tiedonsiirtoratkaisun.
Tarkastellaan ensin ehdotetut ratkaisut ja miksi ne eivät ratkaise sinulla olevia ongelmia.
Tehdasmalli
Tehtaan suunnittelumalli (jota kutsutaan myös tehdasmenetelmäksi) on hyödyllinen, kun haluat käyttää polymorfismia ja haluat erottaa kohteen rakentamisen kokonaan toteutusluokista.
Luokkaperusteisessa ohjelmoinnissa tehdasmenetelmäkuvio on luova malli , joka käyttää tehdasmenetelmiä objektien luomiseen liittyvän ongelman ratkaisemiseen tarvitsematta luotavan objektin tarkka luokka. Tämä tapahtuu luomalla objekteja kutsumalla tehdasmetodi — joko määritetty käyttöliittymä ja aliluokkien toteuttama tai toteutettu perusluokassa ja valinnaisesti ohitettu johdetuilla luokilla — eikä soittamalla rakentajalle .
(kursivointi, minun)
Ja sitä myöhemmin se käsittelee ongelmat, jotka tämä malli ratkaisee:
Tehdasmenetelmän suunnittelumalli ratkaisee ongelmat, kuten:
- Kuinka objekti voidaan luoda jotta alaluokat voivat määritellä uudelleen minkä luokan luodaan?
- Kuinka luokka voi lykätä ilmentämistä alakategorioihin?
Kysymyksessäsi kuvaamasi ongelmat eroavat näistä. Et ole tekemisissä alaluokkien tai polymorfismin kanssa. Tehtaan malli ei ole ratkaisu.
Rakennuskuvio
Rakennuskuvio ( Wikipediasta ):
Rakentaja on suunnittelumalli, joka on suunniteltu tarjoamaan joustava ratkaisu erilaisiin objektien luomisongelmiin olio-ohjelmoinnissa. Builder-suunnittelukuvion tarkoituksena on erottaa monimutkaisen objektin rakenne esityksestä.
(kursivointi, minun)
Tässäkin taas havaitaan ristiriita kuvaamasi ongelman ja tämän mallin käyttötarkoituksen välillä.
Rakentajan suunnittelumalli ratkaisee esimerkiksi:
- Kuinka luokka (sama rakennusprosessi) voi luoda erilaisia esityksiä monimutkainen objekti ?
- Kuinka luokka, johon sisältyy monimutkainen objekti yksinkertaistetaan?
(kursivointi, minun)
Tärkeintä on, että objektin (objekti = 1 esine) rakentaminen on monimutkaista. Tämä voi johtua suuresta määrästä konstruktoriargumentteja tai sen riippuvuuksien kokoamisen monimutkaisuudesta.
Yksittäin kukin rakenne tai luokka on melko yksinkertainen, joten myöskään rakennustekniikka ei sovi hyvin.
Tiedonsiirtomallit (ratkaisu)
Ongelmat, joita todella yrität ratkaista, ovat tietojen käyttöoikeuden suorittaminen, ja etsit ehkä Tietoyhteysobjekti .
Tietokoneohjelmistossa tietoyhteysobjekti (DAO) on objekti, joka tarjoaa abstraktin -rajapinnan tietyntyyppiseen tietokantaan tai muuhun pysyvyysmekanismiin. , DAO tarjoaa tiettyjä datatoimintoja paljastamatta tietokannan yksityiskohtia.
Korvaa tapauksessasi ”tietokanta” sanalla ”tekstitiedosto”. Aiheeseen liittyvä suunnittelumalli on tietovaraston suunnittelumalli , joka jakaa tietojen pääsyn 3 pääratkaisuun:
- arkisto — julkinen käyttöliittymä ”tiedonsiirtotavaroille”
- Yhdyskäytävä — osaa puhua Oracle-tietokantaan tai lukea / kirjoittaa tekstitiedosto. Tähän sisältyisi objektien ja rakenteiden sarjallisuus SQL: ään tai tekstitiedostossa odotettuun datamuotoon.
- Tehdas — yhdistää yhdyskäytävän palauttamat tiedot kohteisiin ja rakenteisiin. käyttää muussa sovelluksessa
Muistin omistusoikeus
Koska sinulla ei ole etua / rajoitusta muistin automaattiselle hallinnalle, nämä objektit ja rakenteet ovat ehdottomasti huolenaihe. Täällä on tehtävä päätös:
- Onko tietojen käyttöobjekti vastuussa tämän muistin puhdistamisesta?
- Onko tietojen käyttöobjekti odottaa soittajan (asiakaskoodi) ottavan vastuun tämän muistin vapauttamisesta?
Jos tiedonsiirtoobjekti luodaan sovelluksen käynnistyessä ja elää, kunnes sovellus suljetaan, datan käyttöoikeus objekti voi ottaa tämän muistin omistukseen.
Jos tiedonsiirtoobjekti luodaan pyynnöstä ja hävitetään, asiakaskoodin on varmistettava, että tämä muisti on tyhjennetty ei määritelty.
Määritä tämä tietojen käyttöobjektin kommenteissa tai ohjeissa ja pakota tämä koodin tarkistuksessa.
Kommentit
- Pidän tästä lähestymistavasta. Näyttää paljon joustavammalta. Kaikki muu, mitä pyydän, paljastaa tietämättömyyteni asiasta. Pitäisikö minun toteuttaa DAO itse? Kuinka ymmärrän sen, minun pitäisi kirjoittaa Gateway and Factory? Onko yhdyskäytävä sama kuin sillan GOF-kuvio?
- Sanon, että arkistokuvion yhdyskäytävä on toinen muunnelma siltakuviosta. Itse asiassa näyttää siltä, että arkistomallin perusta on järjestäytyneempi ja koordinoidumpi silta, joka keskittyy nimenomaan tietojen saatavuuteen. Ja kyllä, sinun ’ sinun on todennäköisesti kirjoitettava nämä komponentit itse.
- Lähettämiesi linkkien seurauksena pääsin en.wikipedia.org/wiki/ODB_(C%2B%2B) , Kuinka tämä ODB sopii kuvaan? Voin kirjoittaa ohjelman muuntaa tekstinsyötön sqllite-tiedostoksi ja käyttää sitten ODB: tä pysyvyyteen? onko tämä ääni? Minun on sanottava, että kompastin vain ODB: hen ja tarkastelin kahta esimerkkiä, joten tämä ei ole tietoinen kommentti.
- Koodin kirjoittamisen apu ei kuulu tämän sivuston aiheeseen, mutta olen ’ varma, että voit muuntaa tekstin sqlite-tiedostoksi ja käyttää olemassa olevaa kirjastoa.
vastaus
Rakennustyökalu ”rakennettaisiin” tehtaan muuttujan (menetelmän) sisään ja lukisi tekstitiedosto, kirjoitat yhden tehtaan menetelmällä lukemaan mainittu tiedosto. Jos sinun täytyy nyt rakentaa mallisi asteittain luetuista tiedoista (ajatella sisäkkäisiä tietoja), tehdasmenetelmän sisäinen rakennemalli palvelee sinua hyvin. Tietojen lataamiseen kuitenkin todennäköisesti riittää yksi malli.
Kommentit
- Jotkut pseudokoodit voivat olla hyödyllisiä kuulemisessa. En ole koskaan käyttänyt tehdas- tai rakennustekniikoita aiemmin.
Vastaa
Rakenteen koon ja monimutkaisuuden vuoksi rakentaja näyttää sopivimmalta, varsinkin jos mallisi on (tai voidaan tehdä) muuttumaton. Sinun on hyväksyttävä tiukka kytkentä rakentajan ja mallin välillä, mutta se on vaivan arvoinen, varsinkin jos sinun on rakennettava malleja useisiin paikkoihin. Rakentajan avulla voit myös kapseloida validoinnin.
Jos mallisi on kuitenkin muutettavissa ja se luodaan vain yhdessä paikassa, tehdas saattaa olla sopivampi ja tarkoituksenmukaisempi ja YAGNI tulee esiin.
Vastauksena toiseen kysymykseesi , sinun ei pitäisi koskaan tallentaa raakaviitteitä C ++: een. Tosiasiassa std::unique_ptr ei ole haittapuolia ja se trivialisoi esineiden tuhoutumisen. Kun kyseinen vektori menee ulkopuolelle, se ei vapauta muistia viitteet kirjoitettuna, mutta ainutlaatuisen_ptr: n kanssa.
Luon vektorin suurille määrille toistuvia elementtejä, varsinkin jos määrä todennäköisesti muuttuu, mutta keskikokoisille komponenteille, joita ei koskaan jaeta, voit yhtä hyvin sisällyttää ne suoraan strukturiin.
Model-luokkaan (tai eri johdannaiset yhteisestä perusluokastaModelBasetaiIModel), ja haluat keskittää päätöksen siitä, mikä konkreettinen derivaatio saadaan aikaan. En näe ’ tätä ongelmaa kysymyksessäsi, joten mikä ’ on ideasi tehtaan käyttämisestä täällä?