ugrás a tartalomhoz

A lepattanó labdák kapcsán (OOP)

eddig bírtam szó nélkül · 2012. Jún. 22. (P), 22.04
Mikor megláttam morocztamás topikját, az első reakcióm az volt, hogy ha már Python, akkor miért nem OOP?
Nem akarok beleszemetelni a témájába, ezért inkább áthozom önálló topikba: ha van egy ilyen, bár nem webes, de egyszerűnek látszó feladvány, hogy néhány golyót kell mozgatni egy 2D-s, grafikus felületen, ezt hogy lehetne objektumokra bontani?
A feladat egyszerűnek tűnik, nem kell semmiféle különösebb fizikával foglalkozni. A mozgó "golyók" (nevezzük inkább korongnak, mivel 2D) véletlenszerű irányba mozognak azonos sebességgel. Ütközéskor a mozgás irányát 180fokkal megfordítom. Hogy melyik irányt (x v. y tengely) az mondjuk attól függ, hogy a korong kerületének mely pontján történt az ütközés.

Már a kiindulásnál elakadtam: a Tiszta kódban azt olvastam, hogy egy osztályról úgy lehet legegyszerűbben eldönteni, megfelel-e a SRP-nek, hogy leírom néhány szóban a feladatát. Amennyiben a leírásban megjelenik legalább egy "és", akkor az az osztály biztosan nem felel meg neki. Sajnos amit el tudok képzelni, azzal nem jön össze.
Egy osztály/objektum lenne a tábla, amin a korongok mozognak.
Ennek van mérete, színe és...
Két feladata: részben konténer jellegű objektum, amelynek egyik feladata a korongok "tárolása", másik feladata a megjelenítés. Máris egy "és" kapcsolat(??? ezen az osztályon/objektumon nem sokat gondolkodtam, számomra a lényeg a Korong osztály lenne)

Másik osztály a Korong nevű, amely a korongokat modellezné.
Ennek vannak olyan tulajdonságai, hogy szín, aktuális pozíció, valamilyen formában tárolva a mozgás iránya. Eddig OK.
És vannak feladatai... Többesszám??? Akkor ez eleve nem lesz jó. De... lehet, hogy mégis, csak én értelmezem rosszul a SRP-t? Mert ugye egy fix sebességgel mozgó korong kapcsán felmerülnek olyan feladatok, hogy mozgatás, ami kiszámolja az új pozícióját a korongnak ÉS ellenőrzi, hogy történt-e ütközés ÉS ha történt, akkor megfordítja a mozgás irányát ÉS tartalmaz egy metódust, amely a grafikus felületre kirajzolja a korongot.

Tudjátok még követni? Hol hibás az elképzelésem? Vagy mit kellene külön osztályokra bontani, hogy egy osztálynak csak egy feladata legyen?
(nem tudom mennyire érzékelhető: nem a konkrét feladat megoldása a vágyam, pusztán jó lenne megérteni, hogy hogyan lehet egy ilyen egyszerű feladatot elemi részekre bontani)

Valahol nagyon belekavarodtam ezekbe a dolgokba. :(
 
1

A Tiszta kódot nem olvastam, DE:

Pepita · 2012. Jún. 23. (Szo), 00.34
Amennyiben a leírásban megjelenik legalább egy "és", akkor az az osztály biztosan nem felel meg neki.
Ez így nem igaz. Ha igaz lenne, akkor return $a + $b; egy önálló osztály lenne, nem pedig egy visszatérő eredmény, valahol eldugva egy osztály valamelyik függvényében. Ha így lenne, akkor a korongod legalább 10 osztályt foglalna magába, ami teljesen felesleges, és lassít(hat)ja a program futását.

OOP = objektumorientált programozás, és != "osztályorientált" programozás.

Szóval - szerintem - a legjobb megközelítés az, ha először főbb egységeiben nézed a feladatot (ezt meg is tetted), azután nekilátsz az egyes egységek tervezéséhez. Ez a szakasz már adni fogja, ha valamelyik részfunkciót érdemes külön osztályban deklarálni, pl. akkor, ha - jelen esetben - a táblának is van egy olyan (nem szimplán számszerű) tulajdonsága/metódusa, mint a golyóknak. Mondjuk, ő is tud mozogni. Ekkor ezt a funkciót érdemes külön osztályban deklarálni, amit mindkét "látható" osztálynál felhasználhatsz. Persze erről a témáról cikksorozatot lehetne írni, de ez az "és" dolog erős túlzás.

az első reakcióm az volt, hogy ha már Python, akkor miért nem OOP?
Nyilván megvan az oka rá. Sokszor (legtöbbször) helyes szemlélet az OOP, de azért vannak kivételek. Pl. nem kell továbbfejleszteni, újrafelhasználni, gyorsaság* fontosabb, mint a szép programkód, "így csak most gyorsan" hamarabb meg tudja írni/kipróbálni, aztán lehet, hogy megy a kukába.

* Amikor még tanítottak Assembly-t az iskolákban, a kezdeti kedvcsináló ilyesmi volt:
Hasonlítsunk össze három programot, mindegyik elszámol 0-10 000 000-ig! Az első valamilyen OOP nyelven íródott, a második struktúrált (pl. TurboPascal), a harmadik Assembly. Már a méretük közt is többszázszoros a különbség, nemhogy futásidőben.
3

Akkor idézem szó szerint...

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 05.17
... a számomra problémás részletet:
A magyar kiadásban, a 156. oldalon kezdődik, "Az osztályok legyenek kicsik!" címmel. Ennek a szakasznak a vége két lappal odébb:
Arra is képesnek kell lennünk, hogy röviden (körülbelül 25 szóban) leírjuk az osztályt az "if" (ha), "and" (és), "or" (vagy), illetve "but" (de) kötőszavak használata nélkül. Hogyan írnánk körül a SuperDashboard osztályt? "A SuperDashboard osztály a fókuszt utoljára birtokló összetevőkhöz nyújt hozzáférést és lehetővé teszi a változat- és felépítésszámok nyomon követését is." Nos, az első "és" szócska világosan jelzi, hogy a SuperDashboard osztálynak túl sok a feladata.


Lehet, hogy túlzásokba estem és rossz oldalról közelítem a témát? Lehet, hogy nem az a lényeg, hogy kizárólag olyan leírást lehessen adni az osztály feladatáról, amely a fenti kötőszavaktól mentes? Inkább az lenne a lényeg, hogy létezzen olyan leírás, amellyel össze tudom foglalni az osztály feladatát ezek használata nélkül?


ui: remélhetőleg még nem a felfogóképességemmel van baj, csak rossz a szemem és egyre nehezebben olvasok hosszabb szövegeket. :(
5

Kicsit necces

Pepita · 2012. Jún. 23. (Szo), 06.43
Nem akarok úgy szembefordulni a könyv szerzőjével, hogy
1. ő maga nem tud róla;
2. nem olvastam a könyvet.

Amit idéztél, az önmagában elég sok szituációban nem állja meg a helyét. De attól még lehet egy jó kiindulási pont, de nem kell véresen komolyan venni. Az élet mindig bonyolultabb (minden téren), mint a könyvbeli példák.

Azt hiszem, túlontúl kisarkítod a dolgokat és igyekszel szó szerint venni mindent. Legyél kicsit rugalmasabb. Egy osztály határait nem lehet ennyire szigorú szabályokkal körülhatárolni, mindig az adott helyzettől/feladattól függ. Sokszor még intuíció is kell a legjobb megoldáshoz.
9

Robert C. Martin...

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 07.51
Többektől olvastam pozitív véleményeket a könyvről, megvettem.
Beleolvastam, és... A katarzis elmaradt, ellenben éreztem valami olyat, mint amikor egy komoly tudással rendelkező ember ír valamit, de az elveiből akkor sem hajlandó engedni, ha nincs igaza.
Úgy képzeltem egy harmincas évei elején járó, egykori "ifjú titán" lehet az illető. Aztán kicsit utánanéztem és... hmmm... Nem nyert. :-)
Ettől függetlenül, valami lehet a megérzéseimben is. :-)
(bocs, nem tudom pontosan idézni a részletet) Egy opensource java kódot boncolgatva mutat egy hibásnak vélt részletet. Itt szerepel egy apró betűs megjegyzés, miszerint a lektorok szerint abban az esetben nincs igaza a szerzőnek. Ezt beleírta, ha már szóvá tették, de ő ettől függetlenül ragaszkodik a maga véleményéhez, hogy az úgy, akkor sem...
-------------------------------------------
Viszont miután ez az egyetlen hitelesnek mondható forrásom(*) igyekszem betartani, alkalmazni mindazt, amit meg tudok jegyezni belőle.
Sajnos ez egy ilyen dolog. Amíg gyakorlatilag 0 alappal próbál az ember tanulni, addig (szerintem) jobb, ha nem akar nagyon rugalmas lenni, mert lehet, hogy hülyeség lesz a vége.

* = pl. a S.O.L.I.D. elvek is tőle származnak, ha jól tudom - épp csak abban tévedtem, hogy ezeket pár éve írták le: állítólag valamikor a nyolcvanas években fogalmazódtak meg :-)
2

A korongnak vannak

szjanihu · 2012. Jún. 23. (Szo), 01.29
A korongnak vannak tulajdonságai, például pozíció, mozgás iránya és sebessége. Azonban ne ő rajzolja ki saját magát. A való életben is az, hogy mondjuk milyen színűnek látod a korongot, függ a megvilágítástól, a látásodtól, stb. Ezekről a korong mit sem tud. Jelen esetben az szerintem kielégítő megoldás, ha a tábla tudja kirajzolni a golyókat. Ezzel elérheted azt, hogy ha később más formában szeretnéd őket megjeleníteni, egyszerűen csak egy másik megjelenítő objektumot kell használnod.

Érdemes elgondolkodni azon, hogy a korongok ütközését jó-e, ha önmaguk vizsgálják? Így elsőre szerintem megfontolandó ennek eldöntését egy külön objektumra bízni, ami ütközés esetén a kérdéses korong objektumokon meghív mondjuk egy hit() metódust. Ez pedig be tudja állítani a korong új irányát, sebességét. Esetleg paraméterben átadhatod neki a másik korongot, ha annak valamely tulajdonsága fontos az új adatok kiszámításához.
4

Na ez két olyan pont, amit a

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 05.38
Na ez két olyan pont, amit a könyvbeli idézetektől függetlenül is problémásnak érzek.
Ráadásul kicsit rosszul is fogalmaztam, azt hiszem.
A tényleges megjelenítés természetesen(?) a tábla feladata, amelyen a korongok mozognak. De azt, hogy hogy néz ki az adott objektum, azt mégiscsak magának az objektumnak illene tudnia saját magáról, nem? (tehát, hogy valóban korong, netán téglalap, ki van-e töltve a belseje vagy átlátszó és csak a körvonalai jelennek meg stb.)

Ütközéseknél mindössze azért tudom nehezen elképzelni ezek külső kezelését, mert szorosan összefüggőnek érzem a mozgatással. Lehet, hogy a korong objektumok csak tulajdonságokkal rendelkeznek és valami "felsőbb hatalom" ( :-) ) mozgatja őket? És ők ebből a mozgásból csak annyit tudnak, hogy ez a felsőbb objektum minden mozdítási ciklusban megmondja, hogy adott pillanatban hol kell tartózkodniuk, milyen a sebességük és irányuk?

Ez utóbbi egyébként megint arra jó példa, hogy miért vagyok bizonytalan a neten található források megbízhatóságában.
Valahol évekkel ezelőtt olvastam egy olyan példát, hogy járművek-(autó,villamos, kerékpár, gőzmozdony)- mindnek vannak különböző tulajdonságaik (szín, méret, tömeg stb) és viselkedésük (mozognak). És ebből vezették le, hogy akkor a tulajdonságok nagy része a "jármű" osztályban definiálható, de a viselkedésüket a leszármazottak tudják csak megvalósítani. Ez így végeredményben igaz, de ha programot írok, akkor... hm... Akkor kinek van igaza? :-)
(nem tudom, így érthető-e, mi bajom van, min értetlenkedek?)

Ütközésnél az eredeti példában leírtak szerint nincs semmi extra, de ha már tovább akarom fejleszteni az egészet, ha fizikát akarok belevinni, akkor az ütközéseket befolyásolják az ütköző objektumok tulajdonságai, de az ütközés eredményeképp ezek a tulajdonságok akár változhatnak is. (pl. rugalmas objektumokat ütköztetek)

Huhh... kezdem azt hinni, hogy kár volt ebbe belemenni, mert nagyon messzire visz.
6

Megbízhatóság

Pepita · 2012. Jún. 23. (Szo), 06.47
...arra jó példa, hogy miért vagyok bizonytalan a neten található források megbízhatóságában.
Ne is legyél biztos sosem, rengeteg a helytelen megközelítés. Sok olyan ember van, aki azt hiszi, hogy már tud valamit, ...
7

Ez nálam úgy húsz éves

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 07.36
Ez nálam úgy húsz éves koromig tartott... Akkortájt estem át a ló túloldalára, azóta mindenben bizonytalan vagyok. (vagy mégsem? :-) )
28

És azt tudod,

Pepita · 2012. Jún. 24. (V), 00.52
hogy a különféle szakmai és "szakmai" tartalmakat hány éves szerzők írják? (Természetesen fentebb a csillogtatással egyáltalán nem rád akartam célozni.) Azonkívül nem a kor számít.

Ha valamit én írok, nem akarom, hogy azért hidd/fogadd el (és mások is), mert én már a 30-at is jócskán elhagytam, hanem azért, mert igazam van. Vagy ha nincs igazam, akkor vitassuk meg, győzz meg, stb. Ezért vagyok "Weblaborfüggő", mert itt így megy, és hamar kisülnek a sületlenségek. Én is szeretek tanulni, de ez még nem ok a bizonytalanságra (vagy igen? :)), viszont kérdésekre annál inkább.
33

Félreértés... :-)

eddig bírtam szó nélkül · 2012. Jún. 24. (V), 08.11
Csak azért említettem a húsz évemet, mert kb. azóta az őrületbe tudok kergetni mindenkit a környezetemben azzal a hozzáállással, hogy semmiben sem vagyok 100%-ig biztos, mindent feltételes módban kezelek. :-)))
(sajnos a háziorvosomat is, ami momentán elég gáz :-((( )
34

A háziorvosokat jobb is

inf · 2012. Jún. 24. (V), 08.38
A háziorvosokat jobb is feltételes módban kezelni, mert általában nem értenek a szakmájukhoz... A nagyon gyakori dolgokat kiszúrják, a többire meg szakember kell.
35

offtopik

eddig bírtam szó nélkül · 2012. Jún. 24. (V), 09.06
Csak az a baj, hogy a szak(???)emberhez beutaló kell, amit a háziorvos ír meg.
Az elmúlt két évben négy különböző szakrendelésen jártam. Ebből egyedül az EKG-t intéző orvosról nem tudtam kialakítani a véleményem, a másik háromnál a háziorvosom is használhatóbb, pedig sehol sincs a régi dokinénimhez képest. Sem emberileg, sem szakmailag. :-(
36

Ja hát tudni kell, hogy hova

inf · 2012. Jún. 24. (V), 10.02
Ja hát tudni kell, hogy hova érdemes menni. Egyébként ha a depresszióval kapcsolatos, akkor felejtsd el a dokikat, mert nincs egyetlen gyógyszer sem forgalomban manapság, ami csak kicsit is használna depresszióra, viszont a mellékhatásaik durvák. Ez ilyen gyógyszercéges pénzbeszedő...

Orbáncfűre mondják, hogy elmúlik tőle a depressziós, meg hogy meg is előzi.
37

Azért a háziorvosok

tgr · 2012. Jún. 24. (V), 10.43
Azért a háziorvosok hozzáértésével kapcsolatos fenntartásokat nem vitatva, még mindig nagyságrendekkel megbízhatóbb a véleményük, mint a "mondják rá, hogy..."
38

:D Vicces vagy... Konkrétan

inf · 2012. Jún. 24. (V), 11.31
:D Vicces vagy... Ilyen témában nem szoktam csak úgy levegőbe beszélni, mert ez a szakmám, a programozás meg csak a hobbim. Sok olyan halálesetről tudok, amikor a háziorvos .ta el, és meg lehetett volna menteni az illetőt. Persze ugyanez igaz szakorvosokra is, sajnos leépült a szakma itthon, mert sokan elhúztak külföldre.

Konkrétan évszázadok óta használják azt a gyógynövényt, és a németek csináltak klinikai kísérletet, ami igazolta a hatását. Ha kell, megkeresem neked. (A németek nagy gyógynövényesek, még Hitler indította be náluk ezt a gyógynövény kutatásos programot.)
39

:-)

eddig bírtam szó nélkül · 2012. Jún. 24. (V), 11.43
Legalább már értem, miért van az, hogy néha 30+ évesnek tűnsz, néha meg másodéves egyetemistának. :-)))
40

Ilyen témában nem szoktam

tgr · 2012. Jún. 24. (V), 13.21
Ilyen témában nem szoktam csak úgy levegőbe beszélni, mert ez a szakmám, a programozás meg csak a hobbim.


Az adatlapod szerint biomérnök vagy, az azért odébb van az orvostudománytól, még ha nem is annyira, mint a programozó...

Sok olyan halálesetről tudok, amikor a háziorvos .ta el, és meg lehetett volna menteni az illetőt.


Néhányról én is. A háziorvos diagnosztizált valamit, a pácienc belehalt valami egész másba, és utólag mindenki nagyon okos volt. Olyat még nem hallottam, hogy előre megmondta volna valaki, hogy nem is A, hanem B betegsége van az illetőnek, és beigazolódott volna. Nem mintha nehéz lenne elképzelni, hogy egy háziorvos súlyos szakmai hibát vét, de sokkal nehezebb utólag megállapítani, hogy valaki szubjektíve helyesen döntött-e, mint hogy objektíve helyes volt-e a döntés. (Főleg, hogy Magyarországon nem divat az egészségügyi adatok gyűjtése.)

Konkrétan évszázadok óta használják azt a gyógynövényt, és a németek csináltak klinikai kísérletet, ami igazolta a hatását.


Aligha találsz olyan emberi fogyasztásra alkalmas anyagot, amiről valaki ne bizonyított volna valamilyen hatást. Csak hát ha egy gyógymód kiértékelése annyiból állna, hogy ráguglizol az interneten, akkor nem kéne öt éven át képezni a leendő orvosokat. A kísérletek nagy részét rosszul végzik el, és kellő szakértelem nélkül nem könnyű kiszúrni, hogy mondjuk az indokoltnál kisebb volt a résztvevők száma, vagy nem a megfelelő statisztikai próbát használták. A korrekt metodológiájú kísérletek is adhatnak számtalan okból rossz eredményt, tehát az összes többi kísérlet eredményével is tisztában kell lenni (vagy metaanalíziseket keresni, de azokról meg még sokkal nehezebb laikusként megmondani, hogy mennyire jók), nem elég találomra kiválasztani egyet és bizonyítékként lobogtatni. És azt se triviális megállapítani, hogy az adott kísérlet releváns-e. Eleve az ICD vagy harmincféle depressziót ismer, ezekből egy kísérletben tipikusan egyet vagy kettőt vizsgálni, és semmi ok nincs feltételezni, hogy az eredmények átvihetőek a többire. Továbbá egy kísérlet eredménye tipikusan vagy az, hogy a szer szignifikánsan hatékonyabb volt a placebónál (ami nem sokat jelent, mert a mintaméret függvényében nagyon gyenge hatás is lehet nagyon szignifikáns - lásd pl. az influenzaellenes homeopátiás csodaszerként reklámozott Oscillococcinummal, aminek a legpozitívabb kísérleti eredménye valami olyasmi volt, hogy átlagosan 4 órával csökkenti az influenzás megbetegedés idejét), vagy hogy hatékonyabb, mint X gyógyszer Y adagolásban, annak az értelmezéséhez meg tudni kell, hogy az az X és Y sok vagy kevés. Szóval nem gondolom, hogy találomra össze lehet guglizni az orvosi szakértelmet, pláne olyan képlékeny témában, mint a depresszió. (Azt könnyen el tudom képzelni, hogy össze lehet guglizni több szakértelmet, mint amennyi a háziorvosnak van - csak itt megint az a probléma, hogy nagyon nehéz megbízhatóan megítélni, hogy mennyi van neki.)

A németek nagy gyógynövényesek, még Hitler indította be náluk ezt a gyógynövény kutatásos programot.


A nácik elég kritikátlanok voltak orvosi programok terén, a homeopátiától az antropozófus orvoslásig mindenféle zöldséget támogattak.
42

Az adatlapod szerint

inf · 2012. Jún. 24. (V), 18.39
Az adatlapod szerint biomérnök vagy, az azért odébb van az orvostudománytól, még ha nem is annyira, mint a programozó...

Konkrétan egészségvédelmi szakirányon végeztem, és két évig jártam át a sotéra, mert elég sok tárgyat ott oktattak. A nyári gyakorlatomat anno Myeloma multiplex diagnosztizálásából csináltam. Általában az egészségügyben a laborvezetők vagy biomérnökök, vagy orvosok, szóval egyáltalán nem áll távol a két szakma egymástól (max a laikusoknak).

nem elég találomra kiválasztani egyet és bizonyítékként lobogtatni

Nem tudom feltűnt e, de a link egy google oldalra mutat 5450 találattal, nem pedig egy konkrét cikkre. Nyilván ezek a tudományos cikkek azért jelenhetnek meg tudományos iratokban, mert előtte elég okos emberek ellenőrzik a helyességüket, és így garantálják, hogy amit olvasol, az a tudomány mai állása szerint igaz. Persze kétségbevonhatod ennek az egész rendszernek a működését, és visszatérhetünk a varázsláshoz, meg a manapság oly divatos ezortériához, engem nem zavar...

Azt könnyen el tudom képzelni, hogy össze lehet guglizni több szakértelmet, mint amennyi a háziorvosnak van - csak itt megint az a probléma, hogy nagyon nehéz megbízhatóan megítélni, hogy mennyi van neki.

Ez nem programozás, nem lehet netről szakértelmet összehalászni, max továbbképezheted / szinten tarthatod magad azzal, hogy tudományos cikkeket olvasol.

Nekem a saját háziorvosommal annyi a problémám, hogy nem ért a szakmájához, és ezt akkora arccal csinálja, hogy az már sok. Nálam konkrétan egy osteoarthritis-t állapított meg csak így ránézésre, mert ropog és fáj az egyik ízületem. Na most egy ilyen embert hogy lehet komolyan venni, aki bármiféle vizsgálat nélkül csak úgy bemondásra diagnosztizál, és nem küld el szakorvoshoz? Pl szemölcsre lazán rávágta, hogy gomba, és hogy kenegessem gombaölővel (inkább elmentem bőrgyógyászhoz). Egyébként tudnék mesélni még rengeteg sztorit róla, de nincs értelme. És akkor ő még a jobbik eset, mert van a környéken egy még ennél is rosszabb... Sajnos ez már rég nem a gyógyításról meg az alázatról szól, az a generáció már kihalt. :S
44

Nem tudom feltűnt e, de a

tgr · 2012. Jún. 24. (V), 21.07
Nem tudom feltűnt e, de a link egy google oldalra mutat 5450 találattal, nem pedig egy konkrét cikkre.


Amelyeknek a nagy részét egyikünk se olvasta, úghogy a találatok számának a lobogtatása mégannyit se ér... amúgy némi kattintgatással találtam közöttük egy review cikket, annak kb. az volt a konklúziója, hogy semmit sem lehet tudni.

Nyilván ezek a tudományos cikkek azért jelenhetnek meg tudományos iratokban, mert előtte elég okos emberek ellenőrzik a helyességüket, és így garantálják, hogy amit olvasol, az a tudomány mai állása szerint igaz.


Hát ez messzemenőleg nem igaz, egyrészt van egy csomó folyóirat, ahol egyáltalán semmit nem csinálnak (nincs peer review), és ezt megint csak nem könnyú kiszúrni ránézésre, másrészt a helyességét nem lehet ellenőrizni egy cikknek, főleg egy vizsgálat eredményeiről beszámoló cikknek (ahhoz minimum meg kéne ismételni a vizsgálatot), legfeljebb azt, hogy a vizsgálat a vonatkozó best practice-ok (kettős vak kiértékelés, kontrollcsoport placebóval, randomizáció, ilyesmik) betartásával történt, és így viszonylag megbízható, de általában még ez sem történik meg; a peer-reviewed cikkek nagy része is módszertani hibákkal teli kísérletről számol be. (Ami nem is különösebben meglepő, a peer review idején a kísérleten már nem lehet segíteni, és senkinek nem használna, ha nem számolnának be róla.) A homeopátiát és a valódi orvoslást összehasonlító híres Lancet-cikk pl. az áttekintett gyógyszerkísérletek 8%-át(!) találta módszertanilag korrektnek.
50

Amelyeknek a nagy részét

inf · 2012. Jún. 25. (H), 03.55
Amelyeknek a nagy részét egyikünk se olvasta, úghogy a találatok számának a lobogtatása mégannyit se ér... amúgy némi kattintgatással találtam közöttük egy review cikket, annak kb. az volt a konklúziója, hogy semmit sem lehet tudni.

Elég irónikus, hogy egyetlen cikket "lobogtatsz", miközben kihangsúlyozod, hogy az ilyesmi mennyire nem helyes...
A cikkek egy része csak így átfutva meglévő antidepresszánsokkal hasonlítja össze az orbáncfű kivonatot, és (bár én kettőt néztem meg csak, de azoknál) az jön ki, hogy van annyira hatékony, mint a meglévő antidepresszánsok. Későbbi cikkekben már mint etalon szerepel, és újabb gyógyszereket / gyógynövényeket hasonlítanak össze vele (tehát elfogadott tény lett, hogy hatásos), illetve van olyan cikk is, ami kizárólag csak ezzel a növénnyel foglalkozik. (Az eredeti állításom, hogy a meglévő gyógyszerek közül egyik sem hatásos depresszióra, túlzó volt, azt visszavonom.)

A Lancet cikket, amire hivatkoztál nem találtam meg, de nem tűnik túl valószínűnek a 8%-os átlag. A homeopátiával kapcsolatban mondjuk el tudom képzelni ezt az átlagot, mert ott szándékosan is ferdíthetik a valóságot, hogy a gyógyszercégek érdekeit tükrözze. (Mondjuk én alapból nem hiszem, hogy placebon kivül más hatása is van a homeopátiának, de ez a magánvéleményem.)
Abban igazad van, hogy fontos egy kísérlet megtervezése, de elég könnyen ki lehet szúrni, ha rossz módszereket használnak, pl nincs ott a címben, hogy double blind, stb... A peer review-ról nem tudok nyilatkozni, a jobb lapoknál pl Nature elég sokat költenek erre, de fogalmam sincs, hogy pontosan milyen az arány. A cikkeknél érdemes megnézni a dátumot, a felhasznált irodalmat, és a hivatkozások számát, ebből elég jól le lehet szűrni, ha valami tudományosan helytálló (sok rá a hivatkozás, viszonylag friss, ha nagyon képből vagy, akkor még akár a szerző neve alapján is). Tetszik, vagy sem, ma ez az elfogadott rendszer a tudományos eredmények publikálására, ha nem vagy kibékülve vele, akkor csinálj egy másikat, és fogadtasd el az egész tudós társadalommal.
51

Hű, láttátok?

Pepita · 2012. Jún. 25. (H), 04.49
Ahhoz képest, hogy mi a témaindító és a cím, egész széleskörű ismeretekre tehetünk itt szert... :)
(Jó lenne, ha legalább a felét kapisgálnám... Ahhoz viszont dr. Pepita kellene legyek.)
52

Ja hát az OOP nagyon széles

inf · 2012. Jún. 25. (H), 05.31
Ja hát az OOP nagyon széles ismereteket kíván meg :D
54

Elég irónikus, hogy egyetlen

tgr · 2012. Jún. 25. (H), 10.58
Elég irónikus, hogy egyetlen cikket "lobogtatsz", miközben kihangsúlyozod, hogy az ilyesmi mennyire nem helyes...


A review cikkek és a clinical trial beszámolók nagyon nincsenek egy súlyban. Pl. ez (a legfrissebb review, amit öt perc kattintgatással találtam) 37 cikket hasonlít össze, és ez alapján jut arra a konklúzióra, hogy Current evidence regarding Hypericum extracts is inconsistent and confusing. In patients who meet criteria for major depression, several recent placebo-controlled trials suggest that Hypericum has minimal beneficial effects while other trials suggest that Hypericum and standard antidepressants have similar beneficial effects. Ehhez képest annak, hogy van két darab cikk, ami mást állít (és jó eséllyel az áttekintett 37 között van), nem sok súlya van.

Ezzel együtt valóban nem igaz, hogy egy darab review cikket (pláne 7 éveset) lobogtatva meg lehet mondani a frankót egy szer hatásosságáról; szerencsére nem is ezt próbálom, csak azt megmutatni, hogy nem olyan egyszerű nem szakemberként megítélni valaminek a hatásosságát, mint amilyennek feltünteted.

A Lancet cikket, amire hivatkoztál nem találtam meg, de nem tűnik túl valószínűnek a 8%-os átlag.


Első találat a lancet+homeopathy keresésre (tényleg elég híres, összesen öt vagy hat szisztematikus review cikk van a homeopátia hatásosságáról, és ez a legfrissebb közülük, és az egyetlen, ami igazán határozottan véleményt mond). Azzal nehéz mit kezdeni, hogy neked nem tűnik túl valószínűnek (gondolom, annyi gyógyszerkísérletet terveztél, hogy már érzésre meg tudod mondani, hogy egy ilyen állítás helyes-e).

Egyébként a tudományos cikkek megbízhatatlansága nem újdonság, rendszeresen írnak róla (mármint szakfolyóiratokban). Pl. A vizsgálatok nagy száma és a metodológia kritériumok szerint súlyozó szisztematikus áttekintések ezt valamennyire ellensúlyozzák (mindenesetre megbízhatóbb a végeredmény, mint bármi más, amit ismerünk), de néhány konkrét kísérletre alapozni a véleményünket nem túl megbízható.

Abban igazad van, hogy fontos egy kísérlet megtervezése, de elég könnyen ki lehet szúrni, ha rossz módszereket használnak, pl nincs ott a címben, hogy double blind, stb...


Sok olyan hiba van, amit nem könnyű kiszúrni. Pl. ha sokféle kritérium szerint hasonlítják össze a vizsgált csoportokat, és rosszul választják meg a statisztikai módszert, akkor sokkal szignifikánsabbnak tűnik az eredmény, mint valójában: ha húsz kritérium alapján hasonlítasz össze, akkor kb. hússzor akkora az esélye, hogy valamelyik kritériumban az egyik csoport "szignifikánsan" jobbnak bizonyul, mint ha csak egy kritérium van. Vagy ha nem publikálták még a kísérlet megkezdése előtt a pontos metodológiát, az is nagyban növeli az eredmények megbízhatatlanságát, de nem egy ránézésre nyilvánvaló dolog.

A peer review-ról nem tudok nyilatkozni, a jobb lapoknál pl Nature elég sokat költenek erre, de fogalmam sincs, hogy pontosan milyen az arány


Erről is rendszeresen cikkeznek, hogy pl. a szerző neve többet számít a peer review kimenetelében, mint az, hogy mit ír. Pl:
The main factors predicting acceptance at the ESC Congress – in line with identified predictors of scientific impact – were the number of enrolled patients (>100) and prospective study design. In contrast, the factors predicting full-text publication in peer reviewed scientific journals were the institutional affiliation of the authors (i.e. university-affiliated institutions fared better than non university-affiliated institutions) and the gender of senior authors (males did better than females), finds the scientometric follow-up in the EHJ study.
(Ez éppen kardiológiai cikkeket vizsgál, de egy csomó más területen is hasonló eredményre jutottak.) A peer reviewra is igaz az, ami a tudományos metodológia nagy részére, hogy jobban működik, mint bármi más, de nem működik igazán jól.

(A lapok egyébként egyáltalán nem költenek peer review-ra, azt a reviewerek majdnem mindig ingyen, társadalmi munkában végzik. Ez csak érdekesség, a fentiek szempontjából nem releváns.)
55

Ehhez képest annak, hogy van

inf · 2012. Jún. 25. (H), 11.28
Ehhez képest annak, hogy van két darab cikk, ami mást állít (és jó eséllyel az áttekintett 37 között van), nem sok súlya van.

Ez egy 2005-ös cikk, az a kettő, amit én néztem emlékeim szerint ennél frissebb. Ha lesz egy kis időm végigfutok a frissebb cikkeken a témában, aztán csinálok egy saját review-t. Gondolom 2005 óta már tisztázták, hogy melyik verzió a helyes (én úgy sejtem, hogy az, hogy hatásos, különben nem cikkeznének róla 2012-ben is.) Egyébként nem az egyetlen gyógynövény, ami depresszióra használ. Az az érem másik oldala, hogy a gyógynövényeknek ugyanúgy vannak mellékhatásaik, csak a legtöbb esetben nem annyira durvák, mint a gyógyszereknek.

A Lancet-es cikkel kapcsolatban én nem homeopátiás cikkekre gondoltam, hanem hogy az összes tudományos cikkre vonatkozóan csináltak egy felmérést (nyilván azt elég nehéz reprezentatívan megoldani). A homeopátiával nem igazán foglalkoztak érdemben a gyógyszercégek, mert nem érdekük. Ha kiderül, hogy használ, akkor azért, ha kiderül, hogy mégsem, akkor meg úgysem hisznek nekik, hiszen nekik az az érdekük, hogy az ő gyógyszereiket vegyék. Másnak meg nem igazán van pénze arra, hogy klinikai kísérletet csináljon a témában. Szóval a homeopátiával kapcsolatban elhiszem a 8%-ot, de általánosságban ez az arány nagyon nem igaz. (A briteknék volt ebből néhány éve vita, azt hiszem ott tb támogatott volt, és visszavonták a támogatását, vagy valami ilyesmi... Ott gondolom ezekre a cikkekre hivatkozva tették mindezt.)
56

A Lancet-es homeopátiás cikk

tgr · 2012. Jún. 25. (H), 12.53
A Lancet-es homeopátiás cikk arról szól, hogy adott betegségekre összehasonlították a homeopátiás és a nem homeopátiás vizsgálatokat, és mindegyikben módszertanilag gyenge volt a többség (a homeopátiás szereket vizsgáló kísérleteknél átlag kb. tízből kettő, a gyógyszereknél tízből egy volt módszertanilag korrekt), viszon a gyógyszereknél nem volt egyértelmű korreláció az eredmény és a módszertani megalapozottság között, a homeopatikus szereknél viszont minél jobb volt a módszertan, annál kevésbé voltak pozitívak az eredmények.

Szóval a 8% az a nem homeopatikus szerekre vonatkozik; el lehet képzelni, hogy más válogatással lényegesen jobb eredmény jött volna ki (mivel itt csak olyan szereket néztek, amik párbaállíthatóak homeopátiás szerrel, vagyis jellemzően valamilyen nehezen behatárolható és placebó-érzékeny betegségre adják őket), de nem elszigetelt eredményről van szó. Pl. itt egy másik cikk, ami szerint a vizsgált tesztek 65%-ánál hibásan számolták ki a szignifikanciát. Általában az egy elfogadott nézet, hogy a publikált kutatások többsége nem túl jó. (És hát persze miért különbözne az orvostudomány bármilyen más szakmától? Általában egy szakma művelőinek a nagy része mérsékelten kompetens.)

A homeopátiával nem igazán foglalkoztak érdemben a gyógyszercégek, mert nem érdekük.


A homeopátia hihetetlenül nagy üzlet, mert a homeopátiás szereket a rendes gyógyszerekkel összemérhető áron lehet eladni (és általában azokhoz hasonló állami/egészségbiztosítási támogatást is kapni rá), ugyanakkor az előállításuk sokkal olcsóbb, mert nem kell tesztelni a hatásosságukat. Úgyhogy a homeopátiás gyógyszercégeknek maximálisan érdeke fenntartani azt a látszatot, hogy tudományosan értelmezhető gyakorlatról van szó. De kezdünk az off-hoz képest is off-ba menni :-)
57

A homeopátia azért jó, mert

inf · 2012. Jún. 25. (H), 14.15
A homeopátia azért jó, mert kihasználja a placebot, és semmibe sem kerül vizes oldatot keverni. Mondjuk ennyi erővel tablettát meg minden mást is árulhatnának placebot :D (Érdekesség a placeboval kapcsolatban, hogy számít a tabletta alakja, színe, formája. Pl fájdalomcsillapításra a kerek piros a jó, nem véletlenül ilyen a cataflam.)

A kísérlettervezés (DOE) egy külön szakma is lehetne. Én tanultam fél évet, de nem értek hozzá így sem. Nagyon komoly statisztikai tudás kell hozzá, viszont nagyon hasznos tud lenni cserébe. Ha több időm lenne, nekiülnék, és megtanulnám rendesen. Így csak tudom, hogy mire jó, meg hogy van ilyen, de nem tudom rendesen használni. Gondolom másoknak is ilyen problémái vannak az alapján, amit írtál.

Ha belenyúlhatnék a tantervekbe, akkor sokkal komolyabban számonkérném a statisztikát az összes tudományos területhez tartozó szakon. Egyszerűen nem lehet nélküle érdemben kísérletezni. (Mondjuk nagyon nehéz jól tanítani...)

Off szempontjából már úgyis mindegy, teleírtuk a topicot :D Mondjuk én ezért szeretem weblabort, mert itt ilyet is lehet...
58

A homeopátia azért jó, mert

tgr · 2012. Jún. 25. (H), 14.38
A homeopátia azért jó, mert kihasználja a placebot, és semmibe sem kerül vizes oldatot keverni.


Gyártani éppen más gyógyszert se drága, csak egyrészt ki kell kísérletezni, ami nagyon drága (sok jól képzett elméleti kutató megfizetése, potenciális hatóanyagok kipróbálása mindenféle állat- és emberkísérletekben), aztán az engedélyeztetéshez randomizált kettős vak kísérletben bizonyítani kell a hatékonyságát sok százas vagy ezres mintákon, hónapokig vagy évekig követve, ami szintén horror összeg (és simán lehet az az eredmény, hogy nem hatékony, és akkor gyógyszer nincs, a pénz viszont elszállt), és aztán mindezeket a költségeket pár év alatt kell behajtani a gyógyszeren, mielőtt megjelenik valami fejlettebb.

A homeopatikus szernél ezzel szemben a kutatás-fejlesztés valahogy úgy néz ki, hogy valaki a homlokára csap, hogy a gülüszemű csüngőlepke taknyából még nem készítettünk semmit, ezekután 5-10 önkéntessel desztillált vizet itatnak, feljegyzik, hogy hogyan érzik magukat, és ha például az egyiknek viszket az orra, akkor bejegyzik a homeopatikus gyógyszerkönyvbe, hogy a gülüszemű csüngőlepke taknya gyógyítja az orrviszketést, és onnantól kezdve bárki árulhat orrviszketésre cukorgolyócskát, ha ráírja, hogy gülüszeműcsüngőlepke-takony van benne milliószor billiószor csilliós hígításban (értsd: nincs benne). Nyilván ez némileg olcsóbb folyamat.

Ha belenyúlhatnék a tantervekbe, akkor sokkal komolyabban számonkérném a statisztikát az összes tudományos területhez tartozó szakon.


Statisztikát az alaptantervbe!

Ilyen téren a leghorrorisztikusabbak egyébként azok a felmérések, amikor a Bayes-tétel ismeretét vizsgálják orvosoknál. Ha millióból egy ember idült gümőkórban szenved, és a vérvizsgálat 99%-os megbízhatósággal mutatja ki az idült gümőkórt, ha van, és 99%-os megbízhatósággal nem mutatja ki, ha nincs, akkor mekkora az esélye, hogy idült gümőkórod van, ha a vérvizsgálatod pozitív lett? Az ilyen jellegű kérdéseket kb. az orvosok 15%-a szokta helyesen megválaszolni.
59

A gyógyszereknél inkább az

inf · 2012. Jún. 25. (H), 14.54
A gyógyszereknél inkább az szokott kiderülni, hogy halmozódik, vagy valami kemény mellékhatása van, stb... Nyilván ezért vizsgálják őket évekig, hogy minden ilyesmi időben kiderüljön. Nagyobb bukás lenne azért visszavonni egy gyógyszert, mert hullanak a betegek, mint amennyit egy klinikai kísérletbe fektetnek... Ez hasonló, mint a programozásnál az utólagos módosítás, minél későbbi fázisban módosítasz valamin, annál többe fog kerülni. Ezért kezdik alacsony költségű tesztekkel, mondjuk egerekkel, stb, aztán haladnak a drágább dolgok felé.
47

Bár nekem nem szakmám,

Pepita · 2012. Jún. 25. (H), 00.38
mégis azon a véleményen vagyok, hogy gyógynövények, természetes hatóanyagok, életmód: igen; gyógyszerek, szintetikus sz..ok : lehetőleg nem.
Egészségesebb így, kevesebb mellékhatás és jóval környezetbarátabb.

A háziorvosokról annyit, hogy az enyém az igencsak ingadozó vérnyomásommal elküldött tüdőröntgenre ("mert ott már rég voltam"), utána még el akart küldeni talán koponya ct-re (hátha hülye vagyok?), de egy 24 órás vérnyomást/EKG-t nem csinált volna, pedig ketyere az van helyben. Na, azóta csak receptért megy a feleségem, én látni se bírom. De lehet, hogy a célját elérte.(?...)
53

Privát üzeneteidet szoktad

eddig bírtam szó nélkül · 2012. Jún. 25. (H), 06.42
Privát üzeneteidet szoktad olvasni?
60

Elnézésed kérem,

Pepita · 2012. Júl. 2. (H), 23.40
most jutottam csak odáig.
Köszönöm, "vettem, vétel".
Jóval több volt, mint amit itt leírtam, más szakik többéves munkája, stb...
8

Én nem olvastam a könyvet! A

Karvaly84 · 2012. Jún. 23. (Szo), 07.41
Én nem olvastam a könyvet! A Python-ban is csak gányoltam amíg rájöttem nem tetszik, de:

A Korong az egy korong ami nem mozog hanem van és kész, Van középpontja és sugara, és csokinyúl....

De tartalmazhat egy objektumot ami mozgatja.

Mint pl. az autó se megy, hanem függ egy Motor objektumtól ami meghajtja.

Ezt UML-ben le lehet modellezni szépen, és talán így nincsenek "ÉS" kapcsolatok hanem mindennek egy feladata van.

A korongot mozgató erő is egy osztály lehet szerintem, és így keletkezik 3 osztály.
10

autó és az ő motorja...

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 07.57
Ez itt nekem nem áll össze: a Motor, az nem egy az Autótól független objektum, ő az Autóban található.
Lehet, hogy rosszul kezelem ezt az egészet? Ha egy objektum, egy másik objektumon belül van, akkor az kifelé "nem számít"?
Tehát ha a mozgást nem szimplán egy metódus intézi, hanem egy másik objektum, akkor a mozgás már nem tartozik az mozgatott objektum feladatai közé?
(Pythont itt nem is akarom belekeverni, általában OO elvekre vagyok kíváncsi, próbálom megérteni, hogy hogyan, milyen alapon lehet egy-egy feladatot objektumokra bontani, mert ebbe mindig belekavarodok, nyelvtől függetlenül)
11

Motor, az nem egy az Autótól

Karvaly84 · 2012. Jún. 23. (Szo), 08.17
Motor, az nem egy az Autótól független objektum
sztem meg igenis független az autótól. A Motort külön be kell építeni az autóba, olyat amilyet a vevő szeretne.

Ezekután mikor elfordítod a kulcsot, nem az autót indítod be hanem a motort. Ami kapcsolva van a sebességváltóhoz, ami a kapcsolva van az autó kerekeihez. És nem az autó hajtja magát hanem a motor hajtja meg azt amihez hozzá van kapcsolva.

Továbbá, vannak az úgynevezett függőségi asszociációk. A motort autó nélkül is be lehet indítani, tehát nem kell hozzá autó, ezért külön osztályba kell tenni.
29

Attól függ

Pepita · 2012. Jún. 24. (V), 01.05
Van autó, amelyik csak egyféle motorral kapható, sőt, a legtöbb motort autó nélkül csak próbapadon tudod beindítani. Akkor kell mindenképp külön osztály a motornak, ha azt más autóba is be akarod építeni.

Nem vitatkozni akarok, de a korongok esetében - szerintem - össz. 3 féle objektumtípus (osztály) van: Tábla, Korong, Megjelenítő.
31

A három az kevés. :)

T.G · 2012. Jún. 24. (V), 07.52
Na de ki irányít? Az is egy önálló osztály.
A megjelenítő pontosan mit csinál? Az egy mindent megjelenítő osztály?
A feladat biztosan megoldható osztályok nélkül is, de ha a cél most az, hogy a SRP-nek megfelelően készítsük el a programot, akkor még néhány osztállyal biztosan ki kellene egészíteni a listát.
48

Inkább hagyom.

Pepita · 2012. Jún. 25. (H), 00.51
Nem akarok rajta vitatkozni, mert ez 100%-ban nézőpont kérdése - és korántsem biztos, hogy az én nézőpontom tanítani való lenne... De azért - gyakorlati ember vagyok - elgondolkodtató, hogy 3-4 2D-s korongot tologatni egy táblán milyen "bonyolult feladat", mert ennyi (mennyi?) osztály kell hozzá. Ebben a példában én a vezérlést simán betenném a megjelenítőbe, ha ez csak egy "próbáljuk ki egyszer" mutatvány, de hansúlyozom, hogy nem ez a tanulandó példa.

Viszont a gyakorlatban sokszor nem éri meg olyan nagy részletességgel szétbontani az osztályaidat, mert nagyon sok require... lesz belőle, és ugye a vrinyó elérésének "egységára" is van.
61

Jellemzően a megjelenítőt

tgr · 2012. Júl. 4. (Sze), 00.06
Jellemzően a megjelenítőt cserélhetőre akarod, mert pl. tesztelésnél valami fake megjelenítőt fogsz használni, ami nem jelenít meg semmit, vezérlésre viszont teszteléskor is szükség van. (Nyilván a kód strukturáltsága mindig azon múlik, hogy mennyire számítasz arra, hogy később módosítani kell. Ha biztos vagy benne, hogy soha többet nem nyúl hozzá senki, akkor OOP-t sem felétlenül érdemes használni.)

A require opcode cache mellett nagyjából zéró erőforrásigényű művelet.
62

Soha nem mondom: soha :)

Pepita · 2012. Júl. 4. (Sze), 06.26
Ha biztos vagy benne, hogy soha többet nem nyúl hozzá senki
Soha nem vagyok (lehetek) ebben biztos.
A require opcode cache mellett nagyjából zéró erőforrásigényű művelet.
Ha használok, igen. Egy ekkor(k)a feladatnál viszont nemigen.
18

Szerintem ott vesztetted el a

inf · 2012. Jún. 23. (Szo), 09.34
Szerintem ott vesztetted el a fonalat, hogy a sebesség és a gyorsulás is az objektumok tulajdonságai. A "mozgató" pedig ezeket használja fel az ő mozgatásukra. A motor a sebességet és a gyorsulást változtathatja.
12

Könyv

morocztamas · 2012. Jún. 23. (Szo), 08.20
A hozzászólásokat nem olvastam el, csak átfutottam, de magára a topicra válaszolva: azért nem oop-vel írom, mert Pythonban még nem tudok és a Tanuljunk meg programozni Python nyelven című Gérard Swinnen könyből tanulok, amelyben még nem jutottam el az oop-ig, de ez a feladat.
13

Költői...

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 08.30
Bocs, az a kérdés csak költői volt. Mondjuk én iskolai feladványra tippeltem (pedig én is abból a könyvből tanulgattam pythonul, épp csak a Tk-s részt átugrottam, mert a PyQt jobban izgatott)
14

clean-code-developer.hu

T.G · 2012. Jún. 23. (Szo), 08.30
Szia! Bob bácsi nem mondd mást, mint bátran hozz létre egy új osztályt, ha új feladatot kell megoldanod. Ne forduljon az elő, hogy „ez még ide belefér”. Merthogy felesleges, a kód nem lesz rövidebb, hogy minden egy osztályba kerül. Viszont átláthatóbb, ha külön van. Ennyi. Ezt szerintem felesleges túlmisztifikálni.

Ajánlom figyelmedbe a következő oldalt: http://www.clean-code-developer.hu/

Nem biztos, hogy sikerélményhez vezeti az embert, ha egyszerre akar minden feltételnek megfelelni, néhányan csoportosították a tiszta kód elveket, kezd el fokozatosan beépíteni a szokásaid közé, ne pedig egyszerre mindet.
15

Köszi!

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 08.56
Köszi!
20

Na ezek alapján én sárgászöld

inf · 2012. Jún. 23. (Szo), 09.39
Na ezek alapján én sárgászöld fokozaton vagyok :-) Persze látom, hogy van még hova fejlődni, csak feleslegesnek érzem a unit teszt írást, amikor 5 percenként refaktorálok és darabolok szét egy osztályt (nyilván ilyenkor az addigi tesztek is módosulnának) ... Előre át kéne gondolnom, hogy milyen osztályokat csinálok, és csak utána nekiállni kódolni...
16

Józan paraszti ész és intuíció

tiku I tikaszvince · 2012. Jún. 23. (Szo), 09.11
Szerintem túlzottan komolyan veszed a Tiszta kódban leírtakat. Nem attól lesz jó vagy rossz az előállított kódod, hogy hiánytalanul betartottad-e az ott leírt alapelveket. Amikor írsz egy új osztályt, akkor időről időre lépj hátra, és nézz rá egységként. Ha már ránézésre is ki tudsz alakítani metódus csoportokat (ezek itt az új pozíciót számolják, ezek meg kirajzolják az aktuális állapotot), akkor kell azt az osztályt szétbontani.

Ha jól végiggondolod, akkor a Tiszta kód is csak annyit mond, hogy szervezd a kódodat logikus egységekbe. Az hogy egy 2 soros ciklusmagot már tedd ki új metódusba, hogy a 4-5 behúzástól tartózkodj, mind "csak" praktikus tanács ezeknek a logikai egységek kialakításához.

Az út, amin elindultál nagyon jó, csak lassan a célt veszíted szem elől. Pár napra veszítsd el a könyvet, feledkezz meg róla (nem fog menni, tudom ;)) és vedd elő a józan paraszti eszed és hallgass a megérzéseidre. Írd meg a kódot, legyél benne teljesen biztos, hogy azt az eredményt adja, amit szeretnél. Csak ezután nézd meg, hogy mennyi mindent csinál. Van ismétlődő feladat? Tedd ki új metódusba! Túl sok az elágazás? Próbáld meg átszervezni! Kis idő múlva már nem is igazán kell majd gondolkodni, mert már a feladat végiggondolása közben, még azelőtt, hogy egy betűt leírtál volna, látni fogod ezeket az egységeket, és ösztönösen el fogod kerülni a csapda helyzeteket és a rossz megoldásokat.
19

Elveszíteni...

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 09.37
Ha tudnád... :-)
Amennyiben normálisan olvasnám és próbálnék belőle tanulni, valószínűleg kevesebb hülye kérdésem lenne, de mióta megvettem, szinte kizárólag buszon ülve olvasgatom, ahol épp kinyílik. (rossz módszer, de...)

Azért próbálom a könyvet követni, mert magamtól nem megy. Túl mélyek a procedurális gyökerek, nem tudok elszakadni tőlük, viszont nagyon szeretnék.
És itt most következne egy másfél oldalas panaszáradat, de megkíméllek benneteket. ;-)
17

Két feladata: részben

inf · 2012. Jún. 23. (Szo), 09.25
Két feladata: részben konténer jellegű objektum, amelynek egyik feladata a korongok "tárolása", másik feladata a megjelenítés. Máris egy "és" kapcsolat(??? ezen az osztályon/objektumon nem sokat gondolkodtam, számomra a lényeg a Korong osztály lenne)


Nem értem, ha tisztán látod, hogy két feladata van, akkor nyilván szét kell szedni két osztályra. Ami a konténer jelleg az a Model, ami a megjelenítés, az a View részhez tartozik...

A mozgatást, és ütközés számolást én szintén egy külön osztályra bíznám, mert azt lehet tovább bonyolítani pl gravitációval, 3d-vel, meg minden ilyesmivel... Lehet, hogy csak annyit hagynék meg a mozgó objektumokból, ami a helyzetüket, mozgásuk irányát, gyorsulásukat, anyagukat és formájukat megmondja, szóval inkább adatstruktúrák lennének, mint objektumok...
21

Azért ez mégiscsak desktop,

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 09.40
Azért ez mégiscsak desktop, nem MVC alapú webes alkalmazás! ;-)

De van benne valami. Azt látom, hogy több feladatot akarnék rákényszeríteni, csak az nem volt tiszta (már kicsit tisztul), hogy hol legyen a választóvonal, mikortól mondhatom azt valamire, hogy ez már nem az osztály attribútuma/metódusa, hanem egy külön osztály.
25

Az MVC asztali

Joó Ádám · 2012. Jún. 23. (Szo), 17.21
Az MVC asztali alkalmazásokhoz lett kitalálva.
26

Ezzel valami nagyon újat

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 17.33
Ezzel valami nagyon újat mondtál... Nekem kimondottan webes megoldásnak tűnt.
27

Az eredeti publikációk,

Joó Ádám · 2012. Jún. 23. (Szo), 22.33
Az eredeti publikációk, amiben Trygve Reenskaug bemutatja az MVC-t, 1979-ben születtek. A web megszületéséig akkor még bő tíz év volt hátra.
32

Akkor még bőven általános

eddig bírtam szó nélkül · 2012. Jún. 24. (V), 08.08
Akkor még bőven általános iskolába jártam... :-)
Itthon pár évre rá meg még ott tartottunk, hogy bemente mágnesszalag (rosszabb esetben lyukszalag v. lyukkártya), a kimenet meg printer. Eszembe nem jutott volna, hogy valahol mrá akkoriban ilyesmin gondolkodhattak.
41

Eszembe nem jutott volna,

Joó Ádám · 2012. Jún. 24. (V), 18.23
Eszembe nem jutott volna, hogy valahol mrá akkoriban ilyesmin gondolkodhattak.


Magyarázat.
43

Bocs, ezt nem értem...

eddig bírtam szó nélkül · 2012. Jún. 24. (V), 18.47
Bocs, ezt nem értem... (illetve remélem, hogy rosszul értem)
45

Ugyanott találták ki, ahol a

Joó Ádám · 2012. Jún. 24. (V), 22.30
Ugyanott találták ki, ahol a Smalltalkot, grafikus felhasználói felületet vagy épp az egeret.
46

Hát nem épp erre gondoltam a

eddig bírtam szó nélkül · 2012. Jún. 24. (V), 23.04
Hát nem épp erre gondoltam a kép láttán. :D
(nem a Telefunkené volt az első egérnek nevezhető eszköz?)
49

nem a Telefunkené volt az

Joó Ádám · 2012. Jún. 25. (H), 00.55
nem a Telefunkené volt az első egérnek nevezhető eszköz?


De, igazad van.
30

Történelem

Pepita · 2012. Jún. 24. (V), 01.25
Ha félre is tesszük Ádám történelmi tényét, akkor is, ha belegondolsz láthatod: egy desktop app. esetében is külön kezeled a felhasználótól érkező kéréseket, az adatfeldolgozást/-kezelést és a megjelenítést. Nincs baj a procedurális szemlélettel sem, de csak ha a megfelelő helyeken használod. Webes területen a HTML előállítása szokott néha hosszabb függvényt igényelni, de ez akkor is - többnyire - egy Model része.
22

A single responsibility

tgr · 2012. Jún. 23. (Szo), 10.00
A single responsibility principle célja számomra alapvetően az, hogy ha egy adott viselkedésre alternatívákat akarsz, akkor ne kelljen a kódot duplikálni. Pl. tegyük fel, hogy van egy World osztályod, ami az elemek nyilvántartásáért és ábrázolásáért felelős. Mondjuk hogy akarsz egy olyan változatot, ami duplán bufferelt (a változtatások egyszerre hajtódnak végre, amikor üt az óra), meg egy olyat, ami nem; és akarsz egy ablakos meg egy karakteres megjelenítést. Ekkor lesz egy World absztrakt ősosztályod, annak egy SimpleBufferedWorld és egy DoubleBufferedWorld gyereke, és azoknak SimpleBufferedAsciiWorld, SimpleBufferedGraphicWorld, DoubleBufferedAsciiWorld, DoubleBufferedGraphicWorld gyerekei, és mivel keresztbe nem lehet örökölni, a a DoubleBufferedAsciiWorld duplikálni fogja a SimpleBufferedAsciiWorld megjelenítő kódját. Ehhez képest ha van külön World és WorldRenderer osztályod, akkor mindegyiknek csinálsz két-két leszármazottat, és nem kell duplikálnod a kódot.

Egyszóval azt, hogy hogy hasítod fel a rendszert osztályokra, alapvetően az határozza meg, hogy milyen cserélhető elemeket szeretnél. (Meg persze az is, hogy mennyire olvasható a kód - ha úgy érzed, hogy egy osztály kódja túl nagy és már nehezen találod meg benne, amit keresel, akkor is érdemes felbontani, de ez sokkal szubjektívebb.) Előre feldarabolni az elképzelhető legkisebb darabokra olyan, mint vízesés modellel tervezni: rengeteg idő, és általában úgyse látod az összes szükséges vágást előre, viszont csinálsz egy csomó felesleges felbontást. Sokkal hatékonyabb csak aszerint bontani, amiről valószínűnek tartod, hogy cserélve lesz, és figyelni arra, hogy a kód könnyen módosítható legyen, ha később bontani kell.

Pl. a konkrét példában lehet egy Body ősosztályod és annak egy Disk gyereke, amitől a korong alakját le lehet kérdezni, egy World, ami a pozíciók nyilvántartását végzi, egy WorldRenderer, ami az ábrázolást, egy WorldTopology, ami megmondja, hogy két pont milyen messze van egymástól (így könnyen lehet például tórusz topológiára váltani, ahol nincs határa a világnak, hanem az egyik oldalon kimenő testek a túloldalon bejönnek), egy kontroller osztályod, ami az időt/léptetést kezeli, meg pár fizika-osztályod (vö. strategy pattern), pl. mozgás meg ütközés - de ha ilyen rendszert kéne írnom, biztos nem használnám első körben ezeknek a felét se. (És akkor külön kérdés, hogy mennyire kell a rendszernek hatékonynak lennie, mert akkor minimalizálni akarod az objektumok és függvényhívások számát. Webfejlesztésnél ez általában nem egy fontos szempont, mert van valami DB kapcsolat, és úgyis az lesz a szűk keresztmetszet, de pl. valami fizika-motor programozásánál már nagyon az.)
23

A példád...

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 11.59
... próbálom megérteni, de nem állítom, hogy tökéletesen sikerült. Illetve talán...

Tehát van egy abstract World, egy abstract WorldRenderer, a World-ből készítek egy SingleBuffered és egy DoubleBuffered változatot, a WorldRenderer-ből egy GraphicRenderer és egy AsciiRenderer osztályt és attól függően, hogy melyikre van szükségem, mondjuk dependency injection segítségével összerakom a megfelelő kombinációt? (pl. a *Buffered osztályok konstruktora paraméterként kapja a megfelelő renderer objektumot)
-----
Ahol fontos a sebesség, ott az eddigiek alapján jó eséllyel kerülném az OO technológiát, amennyire lehet. Valószínűleg objektum orientált eszközökkel felépített, de végső soron egyszerű, procedurális kód lenne a vége, mivel soknak érzem az objektumok kezelésével kapcsolatos overheadet. (bár lehet, hogy csak a tapasztalat hiánya miatt)
24

(pl. a *Buffered osztályok

tgr · 2012. Jún. 23. (Szo), 12.35
(pl. a *Buffered osztályok konstruktora paraméterként kapja a megfelelő renderer objektumot)


Hát inkább fordítva, mert a világ jól elvan megjelenítés nélkül is, a megjelenítőnek viszont szüksége van egy világra. De alapvetően igen, a két osztály teljesen független egymástól, és így teljesen független osztályhierarchiáik lehetnek, és a megjelenítőnek van egy példánya a világból, és attól kérdezi le a pozíciót és egyéb szükséges adatokat.