Ez egy újabb "Java-val akarok programozni" kérdés? Igen!
Sziasztok!
Csírájában szeretném elfojtani: igen, utána olvastam többször is, több helyen. :)
Alapvetően Androidra szeretnék "fejleszteni" saját célra szoftvereket. Itt ne a szokásos csillivili 3D játékokra gondoljatok, hanem arra, hogy olyan programok kellenek nekem, amik megóvnak a sírógörcsöktől (akár grafikus felület nélkül.) :) Tehát tulajdonképpen hobbicélú lenne a dolog, saját örömömre.
Eddig a munkámból kifolyólag csak PLC-t, robotokat és AOI-t programoztam, ami lássuk be, nem az a "mainstream" programozás.
Kutató munkám során nyilvánvalóvá vált, hogy a Java-val kéne barátkozni, de itt jön egy nagybetűs de. Ahogy olvastam a neten, és faggattam a mérnök/programozó kollégákat, mind ellenkező véleményen vannak/voltak.
Van aki szerint C-vel, van aki szerint Pythonnal, van aki szerint nyugodtan lehet Java-val kezdeni. Ez pedig némi bábeli zűrzavart okoz, mivel fogalmam sincs. :) Ha esetleg érvekkel alátámasztanátok a véleményeteket, nagyon szépen megköszönöm!
Továbbá az volna a kérdésem másik része, hogy kaptam néhány Java-s könyvet. Viszont ezek korábbi verziókhoz vannak (1.3-1.6), ez mennyire probléma? Vagy az alapokhoz jó? Mert az angollal nem lenne baj, tehát akár mehetne az Oracle saját tutorialja, de úgy működöm, hogy az anyanyelvemen gyorsabban fogom fel az új szakmai dolgokat. És ugye most egy igen erős alapot kéne lefektetni...
Előre is köszönöm, és bocsánat, hogy ez egy n+1 "hogy kezdjem" kérdés, de tényleg utána olvastam, kollégákat tartottam fel (munkaidőben!), de be kell valljam, el vagyok veszve. Azt tudom, hogy mit akarok megvalósítani, csak nem tudom, hogy úgy-e a hatásosabb, ha egyből előveszem a Java-t, vagy mindenféleképpen kell-e egy másik nyelv.
"Ahogy olvastam a neten, és faggattam a mérnök/programozó kollégákat, mind ellenkező véleményen vannak/voltak."
Ez azért van, mert többféle programozási paradigma létezik:
- imperatív
- funkcionális
- objektumorientált
És még sok más, és mindegyik más-más világot kínál neked. Mindegyiknek megvannak a sajátosságai, külön-külön meg kell érteni őket. Sőt, léteznek ún. multiparadigmás nyelvek, amelyekben mindjárt nem is egy, hanem többféle paradigma szerint programozhatsz, ezeket hívjuk hibrid nyelveknek. Tisztán objektumorientált nyelvek pl. a C#, a Java, funkcionális nyelv pl. az F#, imperatív pl. a C, és hibrid nyelvek a Python, C++.
Lényegében nem nyelvet kell választani, hanem szemléletmódot. Ráadásul ezt is nagyrészt a feladat határozza meg. Ezért nem lehet értelmes választ adni arra a kérdésre, hogy "Melyik nyelvvel kezdjem?". Tegyük fel, hogy adva van a feladat, hogy be kell csavarni egy csavart. Mihez nyúlsz először? A kalapácshoz? Nem... Ha tudom, mi a feladat, már tudom azt is, hogy milyen eszközt (paradigmát, majd nyelvet) válasszak hozzá. Éppen ezért fogom választani vagy a csavarhúzót, vagy a fúrógépet.
Linkelek neked két PDF-et, ezeket nyálazd át:
Az objektumorientált nyelvekről van egy nagyon fontos kulcsmondat a második PDF-ben:
"Az OO programozási nyelvek imperatív jellegűek"
Ezért szokták azt javasolni, hogy ne kezdj egyből az objektumorientált világgal, mivel az imperatív paradigma eszközeire épít. Mintha az objektumorientált világ az imperatív világ kibővítése lenne. Ezért ha az OO-t választod, érdemesebb előtte egy imperatív nyelvvel megismerkedned, hogy tudd, milyen hiányosságai vannak, és mire nyújt megoldást az OO szemlélet.
"funkcionális nyelv pl. az F#"
Ööö... ezt benéztem. Inkább a Haskell lenne jó példa rá.
Köszönöm a válaszokat!
Isten bizony nem akarom rángatni az oroszlán bajszát, de megkérdezem... :)
Akkor ezt elképzelhetem úgy például, hogy okos japán emberek kitaláltak annak idején a Toyota Production System-et, amiből kinőtte magát a LEAN, mint filozófia, amihez tartoznak eszközök is. Viszont attól függetlenül, hogy adott cég használja-e ezeket az eszközöket, még nem lesz LEAN szervezet, mert magát a filozófiát nem veszik át.
Szóval hiába kezdem el mondjuk a Java-t, vagy C-t, vagy bármi mást, ha ahhoz a nyelvhez tartozó paradigmát nem tudom magaménak? Mert mondjuk optimalizálhatom egy adott folyamatot a LEAN eszközeivel, ha az operátorokkal úgy beszél a részlegvezető, mint a kutyákkal, akkor alapvetően borul minden, mert a LEAN alapja az emberek tisztelete, annak hiányában max "hatékonyságról" beszélhetünk.
Ez így ebben a formában helytálló?
Továbbá pl. az objektumorientált programozásra az jó példa, ha a NYÁK tervezést mondom? Tehát lehet úgy tervezni egy adott NYÁK-ot, hogy az áramkör bizonyos részei szépen el vannak különítve már első ránézésre. Azokat nevezhetjük csoportoknak, osztályoknak átvitt értelemben?
Szeretem ezt linkelgetni, mert 5 perc alatt, úgy elmagyarázzák, hogy bárki megérti az OOP lényegét:
https://www.youtube.com/watch?v=SS-9y0H3Si8
Javát akarsz tanulni akkor mivel kezd? Hát Javával!
Mint mondtad vannak programozó kollégáid, az pedig nagy segítség tud lenni. Ha valamit nem tudsz akkor megtudod kérdezni, illetve bele tudsz nézni a programjukba és leshetsz el jó dolgokat :)
Szóval az OOP-ról érthetően és magyarul:
Ha szétnézel magad körül, látni fogsz jó néhány tárgyat. Pl. asztal, ablak, lámpa, szék, csak hogy párat említsek. Hogyan kezdődött ezeknek a tárgyaknak az élete? Leültek és megtervezték. Készítettek egy tervet arról, hogy milyen tulajdonságokkal kell rendelkeznie az adott tárgynak. Az asztal esetében ilyen tulajdonság lehet az, hogy hány lába van, milyen anyagból készült, milyen színű, mekkora a mérete. A tervben azt is leírják, hogy az adott tárgynak milyen cselekvései vannak, és hogyan végzi ezeket a cselekvéseket. Nyilván egy asztal nem tud túl sok mindent csinálni, viszont ha nézünk egy lámpát, az például tud világítani, és az is leírható, hogy hogyan végzi ezt a világítás tevékenységet. Ez mind szép és jó, de ugye egy tervben, papíron létező asztal vagy lámpa még nem létezik, le kell gyártani azt. A gyártás után kapjuk meg a kézzel fogható példányt. A gyártás során dől el az is, hogy az egyes kész termékek tulajdonságai milyen értékeket vesznek fel. Ugyanis lehet gyártani például üvegből készült, átlátszó színű asztalt, de lehet fából készült, barna színű asztalt is.
Eme rövidke példa után nézzük, hogy ennek mégis mi köze volt a programozáshoz.
Mikor egy programot az OOP paradigma szerint készítünk el, ugyanez történik, mint velünk a való életben. Magát a programot fel lehet fogni egy világként. Ahhoz, hogy ebben a világban legyen nekünk valami, terveket kell készíteni, hasonlóan, ahogy mi is megterveztük az asztalt. Egy-egy ilyen tervet hívunk OSZTÁLYnak. A tervben (vagyis osztályban) leírt tulajdonságokat hívjuk MEZŐnek, ami nagyjából ugyanaz, mint egy hagyományos változó. Továbbá, az osztályban leírt cselekvéseket hívjuk METÓDUSnak, ez kvázi a hagyományos értelemben vett függvény vagy eljárás. Ahhoz, hogy a programunk világában ezekből a tervekből, osztályokból "kézzel fogható" tárgy legyen, PÉLDÁNYOSÍTANI kell. Ez az a gyártási folyamat, amelynek során megkapjuk a már használható és létező OBJEKTUMot (más néven PÉLDÁNY). Így első körben azt gondolná az ember, hogy minden, amit az osztályban leírunk, a példányokra is érvényes lesz. Akkor jöjjön az érvágás: ez nem éppen így van. Ugyanis vannak PÉLDÁNYSZINTŰ tagok az osztályban (tag = bármi, ami az osztályban le van írva), amik a példányokra vonatkoznak, és vannak OSZTÁLYSZINTŰ tagok, amik magára az osztályra jellemzőek. Furcsa, de az OOP paradigmában egy "papíron létező" terv is végezhet cselekvéseket, és lehetnek tulajdonságai. Ennek általában akkor van szerepe, amikor nem egy-egy konkrét példányra, hanem általánosságban a példányokról tudunk információt szerezni, műveletet végezni. Erre egy egyszerű példa:
A fájlrendszerben léteznek könyvtárak. Egy-egy könyvtárnak legyen példányszintű tulajdonsága a benne lévő fájlok száma, azok összegzett mérete. Például a C:\valami könyvtárra jellemző, hogy van benne 3 fájl azok mérete összesen 20KiB, vagy C:\másvalami 8 fájllal és 2GiB mérettel. Ezek létező példányok. Ugyanakkor, ami az osztályt magát jellemezheti, hogy hány könyvtár van a fájlrendszerben. Ez természetesen egyik példányra sem vonatkozik, ezért lesz osztályszintű tag.
Az ilyen osztályszintű tagokat szokás STATIKUS TAGnak is nevezni, és a legtöbb programnyelv a static kulcsszóval jelöli. Nézzük meg, hogyan is történik a példányosítás. A példányosítás során a gyártó elkészíti a kész terméket. Az OOP-ben ezt a gyártót nevezzük KONSTRUKTORnak. Így első hallásra elég durvának tűnhet, de csupán arról van szó, hogy a memóriában lefoglal annyi területet, amiben a példányszintű tagok elférnek, továbbá itt szokás kezdőértéket is adni az osztály mezőinek. Ez a konstruktor egy olyan speciális metódus, ami akkor hívódik meg, amikor mi példányosítjuk az osztályunkat. Néhány programozási nyelv, többek közt a Java és a C# is eljárásként kezeli ezeket, olyannyira, hogy a visszatérési érték típusát is tilos kitenni a konstruktormetódus neve elé. Általában a konstruktornak kitüntetett neve van. C#-pban, C++-ban és Java-ban az osztály nevével egyezik meg, PHP-ban __construct névre hallgat.
Az OOP azért jött létre tehát, hogy a mi világunkat modellezzük benne. Ez azért lesz jó, mert jól elkülöníthető részekre osztja fel a mi kódunkat, sokkal jobban áttekinthető az EGYSÉGBEZÁRÁS ELVE miatt. Ez nemes egyszerűséggel annyit takar, hogy a lámpára vonatkozó cselekvéseket nem keverjük össze még kódlogikailag sem az asztal metódusaival és adattagjaival. Ez az összevisszaság leginkább az eljárásközpontú nyelvekben vehető észre, például a C-ben. Bár külön-külön fájlokra oszthatjuk fel a kódunkat, mégsem különülnek el az egyes dolgokra vonatkozó alprogramok. Az egységbezárás elve miatt rögtön jön egy fontos tulajdonság, a LÁTHATÓSÁG. Ennek csupán annyi a feladata, hogy az osztály és a példány tagjait a külvilág elérheti-e. Elvégre elég hülye tervezés lenne, ha például az ember irányíthatná a szívét, vagy beleszólhatnék az autó belső működésébe.
Ember e = new Ember();
e.Szívritmus = 0; //Halott ember vagyok - ezt nem lenne szabad megtennem
Az ilyen esetek elkerülésére az osztály és a példány tagjait LÁTHATÓSÁGI MÓDOSÍTÓval láthatom el. Az OOP paradigma 3 láthatóságot szab meg:
- a külvilág számára elérhető tagok, azaz NYILVÁNOS, PUBLIC
- a külvilág számára nem, de az osztályon/példányon belülről látható tagok, azaz REJTETT, PRIVATE
- a külvilág számára nem, de az osztályon/példányon belülről, valamint az osztályból származó további osztályok számára elérhető, azaz VÉDETT, PROTECTED
Feljött egy fontos definíció, a származtatás, ÖRÖKLŐDÉS. Ez arra lesz jó, hogy én már megírtam, hogyan kell működnie egy lámpának. De én ezt tovább akarom fejleszteni, létre akarok hozni asztali lámpát és csillárt is. Azért lesz ez nekem jó, mert már én egyszer megírtam, hogy mit kell tudnia egy lámpának - és ezt már nem kell többször megírnom, elég csak azt mondanom, hogy a lámpában szereplő tagok alapján létre akarok hozni egy új osztályt. Ilyenkor kvázi "átmásolódnak" a lámpa osztályból a tagok az asztali lámpa osztályba, ugyanakkor én ebből semmit sem látok, csupán ennyit:
class Lampa {
public int Teljesitmeny;
public int IzzokSzama;
public void Vilagit() {
Console.WriteLine("Világít a lámpa");
}
}
class AsztaliLampa : Lampa {
}
Így bevezetőnek ennyit, ehhez még rengeteg definíció tartozik, például helyettesíthetőség, mi az az aktuális példány (this/self), getter/setter metódusok, referencia- és értéktípusok, és még sorolhatnám...
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
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!