Vita:Objektumorientált programozás

Ez a szócikk témája miatt az Informatikai műhely érdeklődési körébe tartozik.
Bátran kapcsolódj be a szerkesztésébe! Jól használható Ez a szócikk jól használható besorolást kapott a kidolgozottsági skálán. Nélkülözhetetlen Ez a szócikk nélkülözhetetlen besorolást kapott a műhely fontossági skáláján. Értékelő szerkesztő: Zafir (vita), értékelés dátuma: 2012. június 2.

Informatikai szócikkek

Wikipédia:Cikkértékelési műhely/Index

két lap egy téma?

Szia!

Ez nem ugyan az a téma mint ami az Objektumorientált programozás lapon van? --- Fgg 2006. május 20., 19:03 (CEST)

Olvasás

Szia!

Három "kritikai" véleményem lenne.
Egyik, hogy azt írod, könnyen átlátható a kód struktúrája a procedurális stílusban, pedig pont ez a hátránya nagyobb programoknál, hogy kusza lesz és ösznyevisznya.
A másik, hogy úgy írod a cikket, mintha az OOP valamiféle fejlettebb, jobb dolog lenne, pedig nem, csak más.
A harmadik, az OOP-t jól írod le, a tulajdonságait, de rosszul alkalmazod a cikkben. Az objektumok használata még nem OOP, pl az én legtöbb programom classokkal dolgozik, akár egész összetettekkel, de ritkán használok öröklődést pl, ami alapvető eleme nekije. – Aláíratlan hozzászólás, szerzője Tetra (vitalap | szerkesztései)

Szia! A cikk alapját még valamikor én írtam. Eredetileg egy gimis beadandó volt :) Aztán ezt a cikket Mr Steve dolgozta át, írta át a példakódokat C++-ra, stb. Én értem ugyan miről van itt szó, de messze nem vagyok a téma szakértője. Csak arra merlek buzdítani, hogy szerkessz bátran! Üdv, Opa  ^vitalap/_unatkozol? 2007. december 18., 00:39 (CET)

Egy: Ha egy mondattal tovább olvastál volna, látnád, hogy a hátrányok is le vannak írva, egyébként teljesen mindegy mert nagyobb programoknál (10000 sor+) nincs az az isten ami átlátható kódot ír paradigmától függetlenül.
Kettő: Ezt mégis hol láttad? Az van leírva, hogy miben más az OOP nem az, hogy jobb.
Három: A cikk sehol nem alkalmazza az OOP -t, ad egy definíciót, van néhány primitív példaprogram és ennyi. A szemléletet nem lehet leírni, ahhoz ,hogy azt megértsd tapasztalat kell, könyvből nem lehet tanulni. Nyilván egy szócikkből senki nem lesz az OOP mestere, ez CSAK definíció.
Azért mert objektum-orientáltan programozol nem kell agyba-főbe a nyelv létező összes elemét használni, nem vadászunk atombombával egérre :)
Szakértőnek én sem merem magamat nevezni, mindig van mit tanulni. A programozás nem olyan mint az orvos munkája (bár mindkettő fontos), hiszen a szív mindig ugyanott van, az informatika pedig egy folytonosan változó terület.
Üdv, – Mr Steve ^vita 2007. december 28., 07:45 (CET)

Kérdés

Mit jelent az hogy "Bizonyos nyelvek megengedik, az osztály függvényeinek használatát annak példányosítása nélkül is" ? Mi az a példányosítás?
John, Doe 2008. július 29., 00:05 (CEST)

A példányosítás, mikor egy osztály objektummá válik, és így használhatjuk az osztályban definiált függvényeket, mint metódusokat. Vannak nyelvek, mint pl a PHP, ahol ehhez nem kell feltétlenül példányosítani, elérhetjük a függvényt az osztályon keresztül is. (PHP-ban :: operátor). – Opa  vitalap 2008. július 29., 00:12 (CEST)

Megközelítésekkel kapcsolatos kérdés

Hali!

Nekem nem egészen világos hogy mi akaródik a megközelítésekben leíródni... Minek a megközelítéseit érted ez alatt? Kicsit nekem az a bekezdés nem feltétlenül ideillőnek tűnik, nem látom mi köze lenne egy funkcionális specifikációnak és egy rendszertervnek az objektumorientált fejlesztési modellhez. Az OOP csak egy technológia amivel egy feladatot meg lehet oldani, a funkcionális specifikáció, és rendszerterv az ettől szerintem független, de nyitott vagyok a kérdés megvitatására.:)

Pifta ^vita 2009. július 25., 01:35 (CEST)

"Jól használható besorolás"?

Ez az egész cikk nagyon szuper, csak éppen az nem derül ki belőle nekem, hogy mi köze ennek az egész hülyeségnek a programozáshoz. Mert ugyan a cikk állítása szerint "nem a műveletek megalkotása áll a középpontban, hanem az egymással kapcsolatban álló programegységek hierarchiájának megtervezése", a programban valaminek mégiscsak meg kellene mondania, hogy mit is kell csinálni. Nem tudom, feltűnt-e valakinek, de a cikk egyetlen példájában sincs egyetlen utasítás sem. Csak adattípus-definíciók. Vagyis csak azt nem tudjuk meg, hogy a létrehozott objektumokat, osztályokat, példányokat mi a bánatra is lehet használni, és főleg: mi a bánatért is kellene nekem ilyen piszok bonyolult örökölgetési struktúrák végigdefiniálgatásával az időmet pazarolnom ahelyett, hogy megírom a programot. Én elég öreg ember vagyok már, ezért én ugyanezt a vakszöveg-stílust végigélvezhettem már egyszer a strukturált programozás matematikai jellegű megalapozásakor, amelynél senki nem tudta megmondani nekem, hogyan lesz ettől kész egy szövegszerkesztő program. "Ilyenkor határozzuk meg a szoftver (formális és informális) specifikációját, majd abból kiindulva kezdjük magasabb szintű absztrakciók segítségével előállítani a rendszer modelljét, amely a konkrét megvalósítás alapját fogja képezni." Úgy van, nekem is pont ilyen semmitmondó szövegből kellett vizsgáznom már harminc évvel ezelőtt is. Csakhogy akkor még külön személyek voltak a kissé elavult szemlélet szerint a programtervező, a programozó és a kódoló, így a programtervező elszórakozhatott az absztrakciókkal, a programozó az algoritmussal, a kódoló pedig megírta ezekből a programot.

De főleg: mitől lesz nem szekvenciális a program, ha nem néhány numerikus vektorban, hanem egymással hierarchikus viszonyban levő objektumok tulajdonságaiban tárolom a tárolnivalót? Vagy ha a szekvencialitás megmarad, akkor üdvös lenne nem ezzel kontrasztban emlegetni az OOP-t.

Az, gondolom, érezhető, hogy én azok közé a kövületek közé tartozom, akik bántó korszerűtlenséggel azzal kezdik a program építését, hogy mit kell csinálnia. Ezért én nem fogom a cikket javítani. De üdvözölném, ha a cikket valaki átdolgozná úgy, hogy kiderüljön belőle, ennek az egész hókuszpókusznak végül is mi köze van a programíráshoz. Lehetőleg olyan tegye, aki olyan baromságot, mint hogy "nagy projektekben kényelmetlenséget okozhat, hogy egy-egy alapvető algoritmust többször, többféleképpen is le kell írnunk, holott lényegi változtatás nincs benne", még akkor sem ír le, ha utána félig vissza is vonja. - Orion 8 ^vita 2012. augusztus 22., 23:22 (CEST)

OOP vs. "procedurális" programozás

Az OOP és a procedurális technika összevetése általánosságban igen nehéz, mivel a különbözö feladatok eltérö megoldási igényei jelentös különbségekhez vezetnek. Egy konkrét környezetben viszont egészen jó összevetés végezhetö el, ez az ügyviteli, üzleti alkalmazási feladatokra felépített SAP ABAP programozási környezete, melyben mindkét technika alkalmazható. Elözményként érdemes megemlíteni, hogy az OOP alapjait jelentö "encapsulation – egységbezárás" és "öröklődés - inheritance" az OOP megjelenése elött már mintegy 10 évvel, nagygépes (mainframe) környezetben az SAP procedurálisnak tekintett fejlesztörendszerének is alapját képezte. A procedurális rendszerben központi Data Dictionary (adatszótár) segít az egységes adatkezelésben, az egyes eljárások (Function Modules) pedig teljes függetlenséget biztosító adatkapcsolati felületen (interface) át érhetöek el. Az összetartozó eljárások akár láthatják is egymás változóit (Function Group), bár e technika kevésbé preferált. Mindezek következtében a procedurális módszerekkel elöállított néhány 10 MB-nyi szöveges kód többsége teljesen átlátható, kódolvasásban és müködés közben (debug) jól követhetö.

Ugyanebben a feladatkörnyezetben az újabb programozó generáció érkezésével megteremtett OO fejlesztöi környezetre támaszkodva jelentös mennyiségü OO kód is keletkezett. Ezek közös tulajdonsága, hogy környezetüktöl erösen elválasztva, ugyanakkor rendkívül csekély transzparenciával müködnek, a nyomkövetés (debug) gyakorlatilag értelmetlen kísérlet az adatfeldolgozási folyamat megértésére.

Az OO helyzetét jelentösen nehezíti, hogy az üzleti környezet igényeinek leképzése folyamatos kódfejlödést igényel, ami a transzparencia (kódérthetöség és követhetöség) folyamatos, sokszor drámai eróziójához vezet, még korábban használhatóan kialakított kódokban is.

A tapasztalatok alapján nagy biztonsággal állítható, hogy üzleti alkalmazásokra a procedurális technika lényegesen kisebb fenntartási ráfordításokkal alkalmazható.