Hogyan keressük meg egy tervben az objektumokat?
Sziasztok!
Ismerkedem az objektum orientált világgal (most éppen a Java-n keresztül, de szerintem a konkrét nyelv nem olyan fontos) és számomra a tárgyban felvetett kérdésre a legnehezebb a válasz. Ha kiötlök egy akármilyen tervet (legyen akár a legegyszerűbb), annak eldöntése a legnehezebb, hogy az alkalmazástól elvárt funkciókat hogyan osztom szét objektumokra ill. osztályokra. A tervezési minták használata nekem még magas (bár sokat tanulok belőlük), a főnevek és igék megkeresése a feladatleírásban sokat segít, de itt meg (és itt kissé ellentmondok az első zárójeles blokkban leírtakra) a használt programnyelv által biztosított eszközkészlet kavar be, egyrészt mert nehéz átlátni egy kezdőnek (na bumm, legfeljebb újra feltalálod a spanyolviaszt, - mondhatjátok - abból is lehet tanulni), másrészt mert sokszor különbözik a különböző programnyelvek esetében. Tehát nem látjuk át mi az amit már készen használhatunk.
Az is nehézséget jelent a főnevek és igék keresésével kapcsolatban, hogy minden alkalmazásban előbb utóbb felmerül az olyan osztályok használatának igénye, melyeknek nincs megfelelőjük a feladatleírásban (például a Java Vector osztálya), ezeket általában nemigen lehet előre látni (legalábbis egy kezdő számára) és olyan, mintha az alkalmazhatóságuk felismerése pont azt a tudást feltételezné, amivel még nem rendelkezünk, amit meg akarunk szerezni.
Tudnátok gyakorlati tippekkel szolgálni? A könyvek mintha "elcsalnák" a kérdést, kevés az igazán kézzel fogható módszer (már ha van egyáltalán módszer). Kinek hogyan esett le a tantusz, illetve mennyire látja át egy tapasztalt objektumvadász, hogy egy vázlatos tervből milyen jól körülhatárolt objektumok fognak kikristályosodni?
Remélem nem bonyolítottam túl a kérdést.
■ Ismerkedem az objektum orientált világgal (most éppen a Java-n keresztül, de szerintem a konkrét nyelv nem olyan fontos) és számomra a tárgyban felvetett kérdésre a legnehezebb a válasz. Ha kiötlök egy akármilyen tervet (legyen akár a legegyszerűbb), annak eldöntése a legnehezebb, hogy az alkalmazástól elvárt funkciókat hogyan osztom szét objektumokra ill. osztályokra. A tervezési minták használata nekem még magas (bár sokat tanulok belőlük), a főnevek és igék megkeresése a feladatleírásban sokat segít, de itt meg (és itt kissé ellentmondok az első zárójeles blokkban leírtakra) a használt programnyelv által biztosított eszközkészlet kavar be, egyrészt mert nehéz átlátni egy kezdőnek (na bumm, legfeljebb újra feltalálod a spanyolviaszt, - mondhatjátok - abból is lehet tanulni), másrészt mert sokszor különbözik a különböző programnyelvek esetében. Tehát nem látjuk át mi az amit már készen használhatunk.
Az is nehézséget jelent a főnevek és igék keresésével kapcsolatban, hogy minden alkalmazásban előbb utóbb felmerül az olyan osztályok használatának igénye, melyeknek nincs megfelelőjük a feladatleírásban (például a Java Vector osztálya), ezeket általában nemigen lehet előre látni (legalábbis egy kezdő számára) és olyan, mintha az alkalmazhatóságuk felismerése pont azt a tudást feltételezné, amivel még nem rendelkezünk, amit meg akarunk szerezni.
Tudnátok gyakorlati tippekkel szolgálni? A könyvek mintha "elcsalnák" a kérdést, kevés az igazán kézzel fogható módszer (már ha van egyáltalán módszer). Kinek hogyan esett le a tantusz, illetve mennyire látja át egy tapasztalt objektumvadász, hogy egy vázlatos tervből milyen jól körülhatárolt objektumok fognak kikristályosodni?
Remélem nem bonyolítottam túl a kérdést.
Mindmap
Gyakorlat
A Vector pont erre példa. Egy teljesen általános célú konténer. Egy probléma megoldva úgy, hogy semmiben sem köti meg a kezed.
Egy másik erőhatás ennek ellenében dolgozik: egy feladat megoldására véges idő áll rendelkezésedre, és nem tudsz mindig a megoldás általánosításába plusz munkaórákat fektetni. Az optimalizálás lényege szintén az, hogy az adott problémára legjobban működő, tehát optimális kódot készítsd. Minél általánosabb egy megoldás, annál kevésbé fog jól szerepelni egy adott esetben, illetve minél jobban "rásímul" a kód a feladatra (optimális) annál kevésbé lesz használható egy másik hasonló feladatnál.
Még egy gondolat: a prototípus. Megírsz egy programot, csak azért, hogy kipróbáld hogy fognak együtt muzsikálni a felhasznált technológiák, vagy mennyire könnyű lesz használni a kész programot. Ezután, ha begyűjtötted a tapsztalatokat, kidobod a prototípust, és újraírod az egészet, ami a valódi terméket fogja adni.
A jövőt nem ismerheted. Megsejtheted, hogy milyen funkciókkal kell majd bővíteni a programot, és ezt figyelembe véve tervezheted meg, viszont mindig lesznek olyan fejlesztési irnyok, amikre nem számítottál. Ilyenkor az egyetlen megoldás a hack (valahogy belegyalázod mégis az új funkciót). Egy idő után ezek a toldozott-foltozott megoldások tönkreteszik a kódot, és olcsóbb újraírni, mint az ezer sebből vérző programot tovább kínozni. A gakorlat segít majd olyan modellt létrehozni, amivel minél ritkábban kell majd újraírni a programjaidat.
top-down, bottom-up
Ha az előbbi ("mind map"?...), akkor gyakran meg kell becsülnie a jövőt.
Nekem a konzulensem a lelkemre kötötte, hogy ne alulról felfelé, hanem felülről lefelé haladjak program(és koncept)fejlesztéskor. Nem mondom, hogy nincs a tanácsban ráció, de így utólag az lett a tanulságom (s érdekes módon a projekt maga is olyan jellegű volt, hogy épp e tárgyban is állást foglalt (természetes nyelvi elemzések stratégiája)), hogy kétséges, mennyivel jobb ilyen esetben a becslések után korrigálni, mint adott esetben a konkrét megoldást általánosítani.
Persze ahol lehet előrelátni, ott kell is becsülni, de ugye most az előre nem látható esetekről szó.