Új hozzászólás Aktív témák

• Karma félisten

  #6972

  #6971 Lacces

  2013-04-17 18:45:46

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Karma

  félisten

  #6971 Lacces

  #6971 Lacces

  "Szerintem a probléma, amit leírsz, nem a creational design patternek témakörébe tartozik."
  Akkor hova tartozik/tartozhat még?
  Bónusz kérdés:
  Milyen más mintákat lehetne még alkalmazni?
  (Igazad van, NoSQL nem SQL, és így valamilyen szinten egyszerűbb dolgom is van.)

  Legegyszerűbb a hierarchia, de ha már hierarchiáról van szó, akkor mindig nézek úgymond egy tervezési mintát, hogy melyik húzható rá?! Valamilyen szinten különbözik egy közép- és felsőoktatási szakkör, na meg egy nyelvi szakkör is. Ha később az egyiket bővítem akkor jó, hogy így szét van szedve logikailag .
  Például a felsőoktatási szakkör csak 1 féléves, a középiskolai 2 féléves(=1 éves), a nyelvi szakkörnél meg lehet "ideiglenes is", mint nyelvvizsga felkészítő. Későbbi módosításoknál.

  "A gyár implementálásához meg szükséged van valami támpontra, hogy milyen szakköröket lehet létrehozni." - Pontosan mit értesz támppont alatt? (Nekem ez így homályos)

  Amúgy köszönöm a segítséget . Még anno a Builder-en gondolkoztam...

  Mindenkinek:
  Mennyire hibás ötlet a következő?
  Lehetne ugye nyelvszakkört kilistázni, ekkor a gyár tudja, hogy nyelvszakkörök lesznek és már ekkor alapból nyelvszakkörös objektumokkal dolgozna? Adatbázisból lekérdezés és a view-ban megjelenítés lista nézetben. Ilyenkor érdemes-e egy újabb view-t létrehozni erre az osztályt típusra, vagy a régit is elég bővíteni(, amely alkalmazkodik a nyelvszakkör adataihoz)? (Gondolom a régit is lehet bővíteni egy bizonyos mértékig).

  Őszintén? Sehova. Esetleg a Fowler-féle enterprise minták valamelyikébe, azokat nem tudom fejből.

  Az előző hozzászólásomból kiemelném ismét, hogy a felsorolt osztályok egyike sem gyár. Sőt, az eddigiek alapján sok viselkedés nem is tartozik hozzájuk, csak adat, aminek adsz egy szerkezetet (magadnak meg fejfájást).

  Apropó Builder, annak is megvan a maga helye, de nem ez. Célszerű elolvasni a minta által megoldott problémát (mindig ott van a definíció környékén), hangsúly most a bonyolult objektum többlépéses inicializációján. Példának meg javaslom a GsonBuilder osztályt a GSON libraryben, látványos.

  Minta tekintetében továbbra is Factory Methodra szavazok (az Abstract változatára nincs szükség, mivel maga a factory csak egyféleképpen létezik), de ha extrémebbre veszed a figurát, használd a Prototype-ot.

  Az említett támpont például egy enum vagy egy string, ami egyértelműen azonosít egy szakköraltípust, és ez alapján hozd létre a példányt/keresd elő a másolandó prototípust. Igen, mindkét esetben (ezekkel a mintákkal) kőbe kell vésned a támogatott típusokat, vagy extra köröket futnod egy reflexiós, classloaderes vagy komponensalapú dinamikus körítéssel.

  Vagy.

  Fogd meg teljesen más oldalról a problémát már a modell szintjén!

  Igazából logika szempontjából két szakköraltípus között semmi különbség nincs, csak mások a tulajdonságai. Megfoghatod meta irányból a problémát: egy szakkör osztály, a közös fix jellemzők tagváltozók, valamint egy Map, amiben az extra tulajdonságokat tárolod. Ha saját osztályt készítesz ezeknek a propertyknek, akkor a "szükséges eszközök listája" jellegű dolgokat például a Composite mintával tudod megoldani. Jé, minta.

  A különböző szakkörtípusok sémává válnak, ami leírja a propertyket. A sémákat külön tudod tárolni, újakat létrehozni, stb. a Java kódhoz nyúlás nélkül. A séma alapján legyártani az objektumot nem nagy kaland, prototípus és factory minta szerint se.

  Ez a metamegközelítés egyébként megjelenítésnél is hasznos, hiszen nem tart semmiből végigiterálni a szakkör propertyjein

Új hozzászólás Aktív témák