Hirdetés
- Kompakt, mégis egyszerűen fejleszthető barebone géppel jelentkezett a Shuttle
- 100 Hz-et tud az ASUS dokkolóval kombinált, ultraszéles monitora
- Egyre inkább szoftverrel segítene a Core CPU-k teljesítményén az Intel
- A szuperintelligencia még odébb, a szuperapp már közel
- Ha Darwinra hallgat az AI, nehéz lesz megállítani
- 4K vs 8K – Megéri-e a 8K TV 2026-ban?
- Túllépne a DRAM limitjein a Neo Semiconductor-féle 3D X-DRAM
- Apple MacBook
- HP notebook topic
- Fejhallgató erősítő és DAC topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kormányok / autós szimulátorok topikja
- RAM topik
- TCL LCD és LED TV-k
- Egyre inkább szoftverrel segítene a Core CPU-k teljesítményén az Intel
Új hozzászólás Aktív témák
-
proci985
MODERÁTOR
válasz
szervizeszso
#8701
üzenetére
melyik része nem megy?
alapvetően én felosztanám a feladatot kisebb egységekre.
kell a szokásos GUI rész, ezt lehet generáltatni. ha nem akarod nagyon túlbonyolítani a struktúrális designt, akkor a GUI és controller class összevonható (én ezt csinálnám, ronda lesz és a cohesion része nem a legszebb, de scope szempontból egyszerűbb). Ezt a classt nevezzük Controllernek.
ha nem kell threaded Person, akkor a controller classba simán raksz egy simulation() funciót egy loopal, ami végighívja mindenkin a meccsnézést annyiszor, ahányan éppen vannak. én ezt úgy csinálnám, hogy fognék egy ArrayList<Married> marriedPairst, amiből a simulation() random kiválasztja a párokat egy temporáris (funkcion scope) tárolóba szintén Married typevel, aztán szépen végighívod a watchFootball() funkciót az összes elemen a temp tárolóban loopban, amit beraksz még egy loopba hogy elégszer nézzék a meccset.
A Marriedben le kell tárolnod egy Wife és egy Man típusú objectet. Ezeket a párokat célszerű még a Controller constructorjában létrehozni (a focicsapatokkal együtt). A Wife és a Mant lehetne inheritelni egy Personból, de mivel a Married eleve egy eléggé domain specifikus funkció amibe szvsz felesleges túlbonyolítás berakni egy generic containert, és mivel az nem kell, ahogy nézem más miatt sincs szükség ezzel a call/information struktúrával inheritre.
Aztán kellenek még a focicsapatok. Én lusta lennék és előre legenerálnám egy listába (Controller constructor, megint), az összes létező lehetséges meccset, majd ezt kalapként használva kihúznék egy elemet amit utána ki lehetne törölni a listából (ha csak egyszer játszhatnak). Meg ide még kell pár funkció.
Aztán kell még a GUIbe egy lista ami lehívja az összes Man és Wifet a Married párokból (lusta megoldás: simán a marriedPairs containerből a married.getWife().getAmikell() loopolva elvileg tökéletes lesz és akkor tényleg nem kell szórakoznod a Person inheritancevel ha ez nem kritikus, sőt a Serializable is max fileIO miatt kell majd), meg kell egy lista a lefutott meccsekkel és az eredményekkel, mondjuk ez meg lehet egy Match class eleme.
Ja félig angolul, de a kulcsszavakat ha nem érted úgy vissza tudod követni pl stackoverflowon vagy a ref manualban.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- A fociról könnyedén, egy baráti társaságban
- Poco F5 - pokolian jó ajánlat
- 4K vs 8K – Megéri-e a 8K TV 2026-ban?
- Túllépne a DRAM limitjein a Neo Semiconductor-féle 3D X-DRAM
- Autós topik
- Graphics: Telefonvásárlási kálváriám....avagy clickbait cím: Horror a hardveraprón
- Linux haladóknak
- Ha Darwinra hallgat az AI, nehéz lesz megállítani
- Arc Raiders
- Motoros topic
- További aktív témák...
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest

