Kezdőoldal » Számítástechnika » Programozás » Ez így nem szép megoldás?...

Ez így nem szép megoldás? Mennyire helyes?

Figyelt kérdés

Van egy Item nevű osztályom, abban ilyesmi propertyk, hogy name, descriptionm, quantity, ... . A konstruktor vár egy paramétert, ami egy ID, és ott beállítja az objektum értékeit az ID-nek megfelelően (mondjuk ha az ID 0, akkor a name="valami", description="valami2"). Vannak itemek (nem sok ilyen), ami csinál valamit, ha rákattintanak. Ezeket egy külön osztály kezeli hasonlóan ID-kkel, mivel több itemnek ugyan az lehet az effektje.


Ezt absztrakcióval szebb lenne megoldani? Én feleslegesnek érzem, mivel sok különböző item van, viszonylag kevés tulajdongással, ezért sokkal egyszerűbb, ha csak az ID állítja be a dolgokat. Ezt így helyesnek tartanám, de mivel pár itemnek van click eventje, ezért az absztrakció jól jöhet, de mivel a legtöbb itemnek nincs ilyenje, talán ezt is feleslegesnek tartanám, és inkább csak kiszedegetem azokat is egy külön osztályba.


A dolog működik, nem ezzel van a problémám, hanem azzal, hogy szépen szeretném megoldani és hatékonyan. Szerintetek?



2019. szept. 22. 14:46
 1/8 anonim ***** válasza:
Vannak gondok :D A forráskód titkos?
2019. szept. 22. 16:35
Hasznos számodra ez a válasz?
 2/8 A kérdező kommentje:

[link]


Kiszedtem a lényeget, ilyesmire kell gondolni. Mivel futás közben nem módosul a quantityn kívül semmi, így nem látom értelmét abstract osztálynak, mert akkor lenne rengeteg kis osztályom, aminek sok értelme nincs. Vagy rossz ajtón kopogtatok teljesen a dolgot illetően? :)

2019. szept. 22. 17:07
 3/8 anonim ***** válasza:
Én nem teljesen értem, hogy a name-et és a descriptiont mért nem adod át ugyanúgy a konstruktornak... ez így elég gány szerintem.
2019. szept. 22. 17:11
Hasznos számodra ez a válasz?
 4/8 A kérdező kommentje:
Az ID-t is menti, azt nem írtam bele a példa kódba. Több osztály is használja az Item-et, így pl. elég az ID-jét lekérdezni, és akkor visszaadja a nevét például. Mivel több osztály is rendelkezik egy Item listával, ezért lehetnek ugyan olyan Itemek csak különböző quantityvel például, és ha máshol hozom létre az Itemet, akkor mindenhol átkéne adnom ugyanazokat a paramétereket, amit az ID átadásával megoldok simán.
2019. szept. 22. 17:16
 5/8 anonim ***** válasza:

Én fel nem tudom fogni mi akar ez lenni, de az a switch horror és az is igen fura, hogy egy osztály saját magáról tartja számon, hogy hány van belőle.

Az absztrakt osztály meg végképp nem tudom hogy jön ide.

2019. szept. 22. 18:16
Hasznos számodra ez a válasz?
 6/8 anonim ***** válasza:

ez így nagyon gány


inkább csinálj az Item mellé egy ItemInfo osztályt, a statikus adatokat szétválasztva a dinamikustól


és jobb lenne ha mondjuk configból olvasnád be, vagy valahonnan és nem így a kódba beégetve tárolnád

2019. szept. 22. 18:57
Hasznos számodra ez a válasz?
 7/8 A kérdező kommentje:

Valószínűleg én vagyok elég érthetetlen, lehet hiányos a leírásom is.


"Én fel nem tudom fogni mi akar ez lenni"

Ez egy inventory rendszer-szerűség egyik osztálya. Vannak különböző itemek, ezeknek különböző tulajdonságai (kő, fa, stb).


"igen fura, hogy egy osztály saját magáról tartja számon, hogy hány van belőle."

Nem tart magáról számon ilyesmit. Az item stackelődhet, 1 sloton lehet mondjuk 32 köved.


"Az absztrakt osztály meg végképp nem tudom hogy jön ide."

Mivel különböző itemek vannak megoldható lenne így is. Ha mindegyik különböző item (kő, fa, stb.) egy Itemből származna, és mivel különböző ClickEvent methodok vannak néhol, ezért absztrakcióval is megoldható lenne. A hátulütője, hogy sok különböző dolog van, és bajos (valszeg felesleges) mindegyikre egy külön osztály.


"inkább csinálj az Item mellé egy ItemInfo osztályt, a statikus adatokat szétválasztva a dinamikustól és jobb lenne ha mondjuk configból olvasnád be, vagy valahonnan és nem így a kódba beégetve tárolnád"

Külön osztályon én is gondolkoztam. Megcsinálom ezt a files dolgot, ez tetszik.


Köszönöm az eddigi válaszokat.

2019. szept. 22. 19:47
 8/8 anonim ***** válasza:

Ezt célszerű lenne kicsit rendszerezni, valahogy így:


Slot: Egy adott inventory slot megvalósítása

SlotItem: Egy slotba kerülő cuccok összessége

ItemInfo: Egy adott tárgy leírása



**Slot**

- properties:

    - slotItem : ?SlotItem

- methods:

    - setSlotItem(?SlotItem)

    - getSlotItem()

    - isEmpty()


**SlotItem**

- properties:

    - itemInfo: ItemInfo

    - quantity: int

- methods:

    - contructor(ItemInfo itemInfo, int quantity)

    - setQuantity(int)

    - getQuantity()

    - getItemInfo()


(Mint látod, az itemInfo mező nem módosítható, azt a konstruktorban megadjuk, és utána fix marad. Megelőztük azt a bugot, hogy változik az itemInfo, de a quantity nem, neadjisten a quantity magasabb mint az adott item típus által megengedett maximum)


**ItemInfo**

- properties:

    name : string

    description: string

    maxStack: int

... me gmég amit akarsz

- methods:

    constructor(name, description, maxStack, ...)

<minden propertyre egy getter, nincs setter>


Az ItemInfo immutable, létrehozás után nem módosítható semmi benne. Célszerű az egyes típusokat előre legyártani egy valamilyen tárolóban tárolni őket. A SlotItemhez pedig ebből a tárolóból fogjuk, referencia szerint behúzni a megfelelő típust.

2019. szept. 23. 00:27
Hasznos számodra ez a válasz?

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

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!