Melyik osztálynak mi legyen a szerepe?
C++
Példa: Van egy Raktár osztályom, amiben vannnak Termék objektumok.
Ezeknek a termékeknek vannak bizonyos jellemzői, amiket fájlokból lehet kinyerni.
(fájl megnyitása, adatok kiolvasása, ezek alapján a Termének megfelelő adatstruktúrákat létrehozni, ...)
/*És erre szükségem van egy jó nagy külső könyvtárra.*/
Egy külső valami meghívja a Raktár TermékHozzáadása(fájlNév) metódusát.
A kérdésem az lenne, hogy az új termék létrehozásánál mekkora szerepet vállaljon a Termék konstruktra és mekkorát a Raktár?
Jelenleg 2 elképzelésem van:
Első:
A Raktár metódusában történik az egész procedúra, és a Termék konstruktorának csak értékeket adok át, amiket az inicializációs listában máris be lehet állítani a tagváltozóknak.
Ennek az az előnye, hogy a nagy könyvtár headerjét csak ebben a "tároló" osztályban kell includeolni, és a raktár feladata a fájlkezelés, stb, nem pedig az egyes termékeké külön-külön. Jobb érvem nincs.
Második:
A Raktár metódusa tovább adja a paraméterként kapott fájlnevet a Termék konstruktorának, és ott a konstrukban végez el minden művelet a betöltéssel kapcsolatban.
Ez nem annyira szimpatikus... mert igazából azért, mert nem olyan, mint az előző :D
Szóval ahogy láthatjátok, nagyon az első felé húz a szívem, de nincs elég érvem, és nem is tűnnek igazán hitelesnek ahhoz, hogy dönteni tudjak.
Szerintetek mit tegyek?
Mégegyszer: Szinte biztos vagyok, hogy az első a jobb, de nincs olyan érvem, ami annyira jó lenne, hogy pl. egy szakmai előadáson is elfogadható legyen.
Szóval valami szakmai érvelést szeretnék tőletek.
(és hogy miért jók/rosszak az én érveim)
válasza:Mindkét elképzelés rossz.
Se a raktárnak, de különösen a terméknek nem kéne tudnia semmiféle fájlokról, mert így függővé teszed az implementációt az adatforrástól.
Egy külső fájlkezelő osztályban kellene beolvasnod a fájlokat és kész termékeket visszaadnod, így az adatforrás teljesen független marad és könnyedén lecserélhető más forrásra, anélkül, hogy az üzleti logikához hozzá kellene nyúlnod.
De ha egy 1 metódusba belefér ez az egész olvasás-készítés procedúra, akkor nem felesleges egy külön osztályt készítenem neki?
Azzal érveltél, hogy más adatforrás esetén könnyedén lecserélhető.
De ha az egész folyamat egy metódusban van, akkor eléggé egységbe van zárva nem?
Végtében ugyanaz: A raktár meghívja egy metódusát egy fájlnévvel, az visszaad egy terméket. A hívó helyen semmit se kell tudni a megvalósításról, és bárhogy lehet változtatni a metóduson, az osztály többi részének csak annyi a lényeg, hogy stringből legyen egy Termék.
Ha pedig ezt osztállyal csináljuk meg, akkor ugyanez, csak nem saját metódust hív meg, hanem egy másik osztályét.
És annyival szebb, hogy így kompaktabb a raktár kódja és egy másik helyen van a fájlkezeléssel kapcsolatos funkcionalitás.
Hoppá, kicsit eltévedtem. Elfelejtettem megemlíteni, hogy az alacsony szintű fájlfeldolgozást a külső könyvtár egy függvényével végzem. Ez betölti és struktúrákba rendezi, és ezután kell nekem fájlkezelés nélkül a feltöltött adatstruktúrákból kiszedni a felhasználandó adatokat.
És az a kérdésem, hogy hol includeoljam a könyvtárat & használjam a függvényt & válogassam ki a hasznos adatokat a feltöltött struktúrákból.
És erre mondtam azt, hogy szerintem a raktárban kéne (amiből csak 1 lehet a program a futása során, de nem követi a hagyományos singleton sablont), és a raktár feldolgozza a külsú könyvtárból kapott adatokat, majd az abból kiszedi a Termékhez szükséges dolgokat és tovább adja a Termék konstruktorának.
válasza:Xml fájlokból olvasol be és egy objektumfával dolgozol? Vagy valami hasonlót sejtek a kérdés mögött.
A külső osztály megoldás az adatok kinyerésére praktikus lehet, csak úgy nem fognak szorosan összetartozni a termék és a termékhez tartozó induló adatok struktúrája.
Számomra a megoldás attól függ, hogy a fájlok felépítése mennyire kapcsolódik a termékekhez vagy a raktárhoz. Pl. ha a fájl szorosan a termékhez tartozik, akkor ahhoz csapnám hozzá, de nem közvetlenül. Csinálnék egy termék-file-handler -szerű ős osztályt, ami csak annyit csinál, hogy a termék fájlból kinyer adatokat, és adatokat visszaír fájlba. Utána ebből származtatnám le magát a termék osztályt.
Ez tuképpen a második megoldásodhoz van közelebb.
Amúgy én a terméket több konstruktorral csinálnám. Tudjon közvetlenül adatokat fogadni paraméterként, és fájlt is tudjon kezelni.
Van egy Raktár osztályod, amiben van egy Termék lista.
a Raktár TermekHozzaadas metódusa a lista végéhez hozzá csap egy új terméket, beolvasod ebben a metódusban az értékeket, és ezzeket adod át a konstruktorának.
De ekkor felmerül egy kerdésem, minden terméknek ugyan olyan adat tagjai vannak ?
Ha igen, akkor ez a legjobb, legegyszerűbb megoldás.
Ha nem, és minden terméknek különböző adattagjai vannak, akkor inkább a fájl nevet add át és a konstruktor csinálja meg a beolvasást, mivel gondolj bele :
- A Raktárnak akkor minden különböző termékhez kell egy külön kis eljárás
- A Termék konstruktorának a parametéterezése is neccesebb lenne, mivel mindegyiknek más más adat tipusa, és mennyisége van.
- És minden különböző terméknek ugyis van egy konstruktora, ezért miért ne hasznaljuk ki azt, hogy átláthatóbb legyen a programunk, és mindegyik csak egz nevet várna, ami a raktárból való meghívást könnyiti.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!