Vita:Objektumorientált programozás

message: 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)
thread_title:  két lap egy téma? 

message: 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. 
replies: text: 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)
replies: text: :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)
thread_title:  Olvasás 

message: 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)
replies: text: 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)
thread_title:  Kérdés 

message: 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)
thread_title:  Megközelítésekkel kapcsolatos kérdés 

message: 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)
thread_title:  "Jól használható besorolás"? 

message: 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ó.
thread_title:  OOP vs. "procedurális" programozás