ugrás a tartalomhoz

php nyelv magyarítása?

Szita Szilárd · 2013. Szep. 10. (K), 12.58
Érdekelne,hogy a php-ban a függvények nevét szeretném átírni magyarra otthoni munkákra.
Hol találok hozzá valami jó dokumentumot?
 
3

Nem mukodik

janoszen · 2013. Szep. 10. (K), 15.47
Legutobb az 5.1-es PHP-ban mukodott turhetoen.
2

Forrás

Poetro · 2013. Szep. 10. (K), 14.26
A PHP nyílt forráskódú alkalmazás, és szabadon módosítható, ezért nyugodtan átírhatod a függvények nevét a forráskódban, majd újrafordíthatod a PHP-t.

Azt ne felejtsd el, hogy bármilyen függvénytárat, keretrendszert használsz, az utána nem fog működni, ha megváltoztatod a függvények nevét.

Egyáltalán mi a célja az egésznek?
4

Szerintem látott valahol egy

H.Z. · 2013. Szep. 10. (K), 16.28
Szerintem látott valahol egy megmagyart office-t, onnan vehette az ötletet.
Egyébként engem is érdekelne, mit akar vele, mert gyakorlati értelmét nem látom. Mire átírja magyarra az összes azonosítót, egyrészt kijön két újabb verzió, másrészt addigra épp megtanulja az összes angol nevet és mehet a kukába a magyarítása ("otthoni munkára")
5

Rendben

Szita Szilárd · 2013. Szep. 10. (K), 16.29
Rendben köszönöm az eddigi válaszokat, most lenne egy egész más kérdésem.


Na tehát az van, hogy idén nekem érettségi, és van nekem arra lehetőségem, hogy a php nyelvet válasszam így arra a döntésre jutottam, hogy php lesz, úgy is érdekel a dolog meg minden.
van 1 évem elkezdeni az egészet, foglalkoztam már php-val eléggé sokat, de komolyabb dolgokat nem csináltam vele.
Na és akkor most jönne a kérdés nekivágjak ennek, 1 év alatt sikerülhet az alábbi tervem, de ha nem akkor sem gond legalább jó gyakorlási feladatokat kapok.


Elképzelésem, hogy írok egy online stratégiai játékot természetesen egy butított változatot egyszerű kattintgatós játék lenne a következő funkciókkal.
Első és nem utolsó sorban: belépés, regisztráció, jelszó emlékeztető, ez a külső rész.

Játék magja tartalmazná : Főoldal, profil, profilszerkesztés, banda, bank, küzdelem, box, rablás, autólopás.
Ezek lennének a főbb funkciók az oldalon, így első ránézésre nem is tűnik olyan vészesnek mert nem is az, megoldható egy kis tanulással.
Igaz a védelemmel és az OOP-sal nem vagyok tisztában.
Szerintetek?
6

Igaz a védelemmel és az

Poetro · 2013. Szep. 10. (K), 17.30
Igaz a védelemmel és az OOP-sal nem vagyok tisztában.
Szerintetek?

Hát az ügyben nem tudok nyilatkozni, hogy tisztában vagy-e velük.

Maga a feladat tűnik nagyon komplexnek a rendelkezésre álló időhöz képest, és meg is valósítható PHP-val. Persze nem tudjuk, mik az egyes funkciók. Nem derült ki, mi a banda, box, kűzdelem, rablás, autólopás és a külső rész.

Mondjuk előbb talán jó lenne a központozás használatát is mélyebben elsajátítani, mert nagyon nehézzé teszi a mondandód elolvasását a hiányuk illetve nem megfelelő használatuk.
14

Mondjuk előbb talán jó lenne

Joó Ádám · 2013. Szep. 11. (Sze), 11.42
Mondjuk előbb talán jó lenne a központozás használatát is mélyebben elsajátítani, mert nagyon nehézzé teszi a mondandód elolvasását a hiányuk illetve nem megfelelő használatuk.


Horribile dictu megbuktatnak a magyarérettségin :)
15

A helytelen írás

Hidvégi Gábor · 2013. Szep. 11. (Sze), 11.49
A helytelen írás programozáskor is nem várt eredményt hozhat.
31

Na és,

Pepita · 2013. Szep. 14. (Szo), 03.20
Poetro nem hiszem, hogy magyar érettségire készülne...
Ellenben azt gondolom, hogy mostanában igen keveset beszél-ír magyarul, ami nem jó.
35

Ki beszél itt Poetroról? :)

Joó Ádám · 2013. Szep. 14. (Szo), 12.29
Ki beszél itt Poetroról? :)
40

Nem te?

Pepita · 2013. Szep. 14. (Szo), 23.33
Nem az idézett mondata miatt akartad őt megbuktatni 14-ben? Nekem úgy néz ki.
Ha valamit nagyon elnéztem, akkor bocsi, de lehet inkább te voltál félreérthető... :)
43

Mindketten Szita úrhoz

bamegakapa · 2013. Szep. 15. (V), 00.14
Mindketten Szita úrhoz beszéltek.
8

Nézd, szerintem amíg nem vagy

bamegakapa · 2013. Szep. 10. (K), 19.07
Nézd, szerintem amíg nem vagy tisztában a "védelemmel", az OOP-vel (illetve inkább a kódszervezés fortélyaival, azt meg lehet tanulni objektumok nélkül is, de ma az OOP népszerűbb, ezért több az anyag is) és úgy általában a PHP-vel sem, semmi értelme belekezdeni egy nagy projektbe. Lehet, hogy útközben sokat tanulsz majd, de mivel az ember a projekt elején az alapok lerakásával kezdi, azok pedig a legfontosabbak és pont akkor értesz majd a legkevésbé a dologhoz, amikor ezeket csinálod, így nagy eséllyel gyorsan átláthatatlan, kezelhetetlen, lélekölő spagettikód halmazzá alakul a rendszered. Az iskolában ráadásul kb. 0,5% esélyed van, hogy olyan tanárt fogsz találni, aki segíteni tudna neked ebben.

Én azt javaslom, kisebb feladatokat, projekteket csinálj, amiket viszonylag gyorsan befejezel, esetleg könnyen újra is tudsz írni, ha már többet tudsz és szükségét érzed. Olvass sokat (angol nyelv nagyon kéne), tanulj sokat, gyakorolj sokat, tanulmányozd népszerű projektet kódját.
10

Kódszervezésre tudsz

jgege · 2013. Szep. 11. (Sze), 09.00
Kódszervezésre tudsz valamilyen jó könyvet ajánlani? :)
13

Én a netről gyűjtögettem az

bamegakapa · 2013. Szep. 11. (Sze), 09.59
Én a netről gyűjtögettem az infót, könyvet nem olvastam a témában. Valaki biztos fog tudni segíteni ebben.

Igazából az egyetlen szakmai könyv, amit valaha elolvastam, az a Javascript The Good Parts a jó öreg Crockfordtól, de az nem kódszervezésről szól, legfeljebb érinti.
22

clean code

inf3rno · 2013. Szep. 11. (Sze), 15.00
clean code
9

Valami nagyon alap szinten

inf3rno · 2013. Szep. 11. (Sze), 01.40
Valami nagyon alap szinten meg tudnád csinálni egy év alatt, de én inkább azt ajánlom, hogy csinálj valami egyszerűbb webalkalmazást, mondjuk blogot vagy fórumot, vagy bármi ilyesmit egy keretrendszer segítségével, pl symfony, zend, stb... Tanulj meg git-et használni és egy IDE-t mellé, mondjuk netbeanst. Érettségi tudásnak már ez is bőven sok, az alkalmazás, amit felvázoltál - nulláról indulva - meg sok éves munka lenne neked...

Ami talán a legfontosabb, hogy tanulj angolt ezerrel! Anélkül még a manualt sem fogod megérteni, nem hogy programozni valamilyen keretrendszer alatt...
11

Tehát szeretnél infóból

jgege · 2013. Szep. 11. (Sze), 09.03
Tehát szeretnél infóból érettségizni és úgy gondoltad, hogy programozási feladat megoldásához PHP-t választasz? Ez eddig oké, viszont érettségi feladatnál teljesen más dolgok vannak mint amit pl egy ilyen játéknál használni fogsz. Nézd át az elmúlt évek feladatait. (fájlból olvasás, fájlba írás, különböző alapalgoritmusok amiket jó eséllyel nem fogsz használni egy ilyen projektnél)

Ellenben a többiekkel én azt mondom, hogy állj neki. Régebben én is úgy voltam vele, hogy volt egy ötletem, neki álltam, ha valami nem ment akkor változtattam a terven, de legalább szerettem és csináltam :) Amíg nem megrendelésre dolgozol addig ezzel szerintem nincs is semmilyen probléma. Ahogy előttem írták a spagetti/lélekölő kód az lesz, de anno ezzel valahogy nem volt problémám, változtattam a terveken :D

Legnagyobb projektem még érettségi előtt egy mászkálós játék volt. Tipikus felül nézet, graf összeszedve netről. Még pályaszerkesztőt is csináltam hozzá :D Sokból végül is nem állt kezdőpont, cél, fa(mint akadály), doboz(mint mozgatható akadály), levél (amit össze kellett szedni). Először amikor neki álltam csak kezdő, végpont, fák voltak, végén - mivel nem volt nehéz megoldani - jöttek a fentebb felsoroltak. Szerettem volna bele kapukat amiket különböző színű kulcsokkal lehetett volna nyitni, de mivel sok mindent át kellett volna írnom hozzá (nem a legtutibb struktúra) így ahhoz már nem volt kedvem (na bumm!). Azért csináltam mert élveztem. Ha neked sincs más célod vele akkor kezdj bele és legyél rugalmas a terveiddel kapcsolatban :) Anno ezzel elvoltam jó ideig (az megmaradt, hogy volt egy olyan nap amikor reggeltől estig a gép előtt ültem és csináltam), nem rég neki álltam C#-ban és 2 óra alatt kb meg volt, igaz csak konzolon, de a struktúra sokkal jobb :D

Miért várják el a tanárok, hogy a diákok megértsenek megoldásokat amiket olyan problémákra hoztak létre amivel a diákok még nem találkoztak?


szerk.: így, hogy látom miért akarod: ne akard átnevezni a php függvényeit :D
12

+1

szabo.b.gabor · 2013. Szep. 11. (Sze), 09.06
valahol tényleg el kell kezdeni.

(: az első (na jó második) oldal amit majdnem megcsináltam táblázatos volt természetesen, de annyira nem futotta, hogy táblázatokat egymásba lehet ágyazni, így komoly rowspan és colspan matek volt benne, mire összeállt egy-egy layout :D

aztán voltak egyéb cudar dolgok is.

a lényeg, ha teheted próbálj meg (több) csapat tagja lenni, józan paraszti ésszel úgyis rájössz, hogy kitől érdemes tanulni, próbálj meg saját megoldásokat létrehozni, és kóstolj bele frameworkokbe is.

ha akarod csináld, nem kerül semmibe az idődön kívül.
16

Tehát szeretnél infóból

Joó Ádám · 2013. Szep. 11. (Sze), 12.07
Tehát szeretnél infóból érettségizni és úgy gondoltad, hogy programozási feladat megoldásához PHP-t választasz? Ez eddig oké, viszont érettségi feladatnál teljesen más dolgok vannak mint amit pl egy ilyen játéknál használni fogsz. Nézd át az elmúlt évek feladatait. (fájlból olvasás, fájlba írás, különböző alapalgoritmusok amiket jó eséllyel nem fogsz használni egy ilyen projektnél)


Én épp ezért mondom azt, hogy felejtse el, hogy érettségin mást használ, mint amit tanítanak neki, ami majdnem biztos, hogy Pascal. Én is kalandvágyó ember voltam, én ugyan nem fogok egy ilyen nyelvet és főleg egy ilyen IDE-t használni, nekifutottam a C++-nak. A vizsgahelyen derült ki, hogy az IDE-nek nincs olyan billentyűsémája, amiben valamely viszonylag fontos írásjelet ({) eredményező billentyűkombináció ne dobna fel egy ablakot, meg például futtatáskor nem nyíltak meg a fájlok, így vakon kódoltam le az ezen alapuló feladatot. Már amit le tudtam kódolni, mert nem biztos, hogy ment az algoritmus. És még csak fel sem ismertem akkoriban, hogy hány- és hányféleképpen törheti össze magát az ember C++-szal.

Tehát nem, semmiféleképpen nem ajánlom, hogy PHP-t használj az érettségin. A legkevesebb, hogy senki nem lesz, aki felkészítsen, és hogy nem nézegetheted a php.net-et vizsga közben. De számíthatsz rá, hogy nem fog sikerülni összehozniuk egy működő környezetet a vizsgahelyszínen, és nem egy kellemes élmény, amikor ezzel szembesülsz, és elkezdődik a hercehurca. Továbbá a PHP, mint gyengén típusos és meglehetősen következetlen nyelv közel olyan veszélyes egy kezdőnek, mint a C++, mert a logikát, mint segédeszközt kidobhatod az ablakon, a fordító pedig semmilyen segítséget nem fog adni a hibák felderítésében. Mindezen felül pedig egy webalkalmazásban (legalábbis egy naiv megvalósításban, amit kezdőként írsz) töredékét sem fogod használni azoknak a technikáknak, algoritmusoknak, amikre szükséged lehet a vizsgán.

Összefoglalva: még ma telepíts fel egy népszerű Linux disztrót (magyarul Ubuntut), tanuld meg az érettségiig magabiztosan használni; tanuld meg a Pascalt a-tól z-ig (nem nehéz, mert sokkal összeszedettebb nyelv, mint mondjuk a C++); használj hozzá valami jó kódszínező szövegszerkesztőt és parancssoros fordítót, véletlenül se az elcseszett IDE-ket; és vegyél egy alapozókönyvet algoritmuselméletről.

A fentieket nem kötelező megfogadni, de én ezt tanácsolnám magamnak ma, pedig én már programozgattam pár éve, amikor érettségiztem.
17

Kérdés, hogy tanítanak-e neki

jgege · 2013. Szep. 11. (Sze), 13.30
Kérdés, hogy tanítanak-e neki valamit... :)

Szita Szilárd: tanulsz suliban programozni valamilyen nyelven? Ha igen milyen nyelven?

Ubuntun anno próbáltam Lazarust - mert kellett egy IDE amibe össze tudok húzogatni -, ebből a tapasztalatból kiindulva kiindulva meg abból, hogy egy kezdőnek néha milyen fejtörést tud okozni a linux jobb ha WINen marad amit gondolom használ mindennapokban :D

és vegyél egy alapozókönyvet algoritmuselméletről

Van olyan könyv ami jó is és nem a tipikus régi módszer szerint próbálkozik? (Agyhullám - HeadFirst - féle tanítás sem jött be).
Ilyen könyvről is elfogadnék ajánlást :)
18

Ubuntun anno próbáltam

kuka · 2013. Szep. 11. (Sze), 13.38
Ubuntun anno próbáltam Lazarust (…) ebből a tapasztalatból kiindulva kiindulva
Biztos helyesen vonod le a következtetést? Az én észrevételem szerint Lazarus Linuxon és Windowson egyaránt tud fejtörést (illetve tépésből eredő hajhullást) okozni. De ez kizárólag a Lazarust minősíti, nem a Linuxot.
19

Itt kifejezetten - bár

jgege · 2013. Szep. 11. (Sze), 14.17
Itt kifejezetten - bár lehetséges, hogy nem fogalmaztam egyértelműen - a Lazarussal volt bajom, win-en Turbo Delphi 2006-al nyomtuk az pedig elég stabil volt :D

Linux egy kezdőnek még mindig tud fejtörést okozni pl win-en egy wampot feltenni next-next-finish linuxon pedig, hogy fájlokat tudj másolni a LAMPP által létrehozott könyvtárba (/opt/lampp/htdocs) már google és terminál kell.
A Linux jó, a linuxot szeretjük, de ha szeretnél rajta fejleszteni több tudás/kalandvágy kell, mint a winhez. (nem is baj :D)
Ubuntu legutóbbi kiadásaival nem vagyok kibékülve :) Első találkozásom vele még a 8.04 volt, XPhez képest elmondhatatlan volt a különbség. Gyors bootolás, testreszabhatóság, stabilitás, látvány és még azt hiszem lehetne sorolni. Otthon a nem pozitív változásoktól függetlenül még mindig ubuntuzok, de keresek egy jobb disztrót :)
21

Kifejezetten hangsúlyoztam,

Joó Ádám · 2013. Szep. 11. (Sze), 14.38
Kifejezetten hangsúlyoztam, hogy ne használjon IDE-t, mert az csak bonyolítja az egészet, ami így is elég bonyolult. Egy IDE-nek meg kell ismerni a felületét, be kell konfigurálni, vakarni kell a fejed, hogy hogyan linkelsz stb.

Ha egy sima szövegszerkesztőt használsz és egy parancssoros fordítót, akkor csak azt az egy parancsot kell tudd, amivel fordítasz.

Windows-on viszont csak az IDE-k dívnak, ezért mondtam, hogy tanuljon bele egy desktop Linuxba.
23

Igen láttam és ezt olvastam

jgege · 2013. Szep. 11. (Sze), 15.03
Igen láttam és ezt olvastam is. Mi JAVA-nál használtunk parancssoros fordítót első körben, de évek alatt rájött a tanárunk, hogy egyeseknek ez problémát okoz (:D) úgyhogy valahogy a SCITEhoz nyúlt úgy hozzá, hogy telepítés nélkül lehessen fordítani, futtatni :D Nem mintha ez sokat változtatott volna az osztály eredményein, de kicsit növekedett az esély :)))))

Egy kezdőnek (anno én így voltam vele) sokkal idegenebb lehet parancssorozni. Főleg Pascalhoz (írtad, hogy valószínűleg ezt tanítják neki) amilyen IDE-t használtunk nem volt sok probléma a configgal (emlékeim szerint).

Sima szövegszerkesztőbe nem tudom mi fér bele, de kód kieg életet ment(het ) főleg érettségi alatt.

Ha PHP-t nézünk akkor teljes mértékben megértem azt, hogy próbálod elterelni ezektől :)
24

Ja, ebben szerintem igazad

inf3rno · 2013. Szep. 11. (Sze), 15.08
Ja, ebben szerintem igazad van, ha tényleg úgy megy az érettségi, hogy elétolnak egy használhatatlan fejlesztői környezetet egy teszt feladattal, akkor jobb, ha nem használ IDE-t, hogy szokja... Én speciel IDE nélkül már neki se állnék fejleszteni, de ugyanúgy van ez, mint a vezetéssel, egész máshogy vezet az ember sok év után, mint amit egy forgalmi vizsgán elvárnának...
32

Ubuntu - fenének

Pepita · 2013. Szep. 14. (Szo), 03.52
Több időt eltölt a megtanulásával, mint keres egy ősrégi DOS-os "IDE"-t. Pl. nekem a Turbo Pascal 6.0 megvan még (van itt valaki olyan "öreg", aki ismeri?), és a WinXP cmd.exe-je alatt is műxik. Felmásolod egy pandrive-ra és viszed az "IDE"-t az érettségire is.

- Se kódkieg., se semmi, de:
- Help a parancsokhoz,
- Menüből ellenőrzöl, fordítasz, akár futtatsz is,
- A suliban (érettségin) megnézném, hogy van-e Linux.

És ne felejtsük el: nem 1 év, hanem egy nem egész tanév áll rendelkezésre. Ha már Pascal, akkor valami ősi, de nem parancssoros fordító, nem tud mit kezdeni a hibaüzikkel,ha egyáltalán vannak. De ma már nem lennék meglepve, ha nem Pascal menne + nem mondta, hogy tanítanak-e valamit e tárgyban, gőzöm sincs a mostani érettségi szabályokról, lehet tök önállóan készül ebből.

Ja, és gondolom nem ez az egyetlen, amiből le szeretne érettségizni...
33

Turbo Pascal

Hidvégi Gábor · 2013. Szep. 14. (Szo), 07.16
5.0-val kezdtem a gimnáziumban, aztán bejött a 6-os, szóval én ismerem : ) Sőt, még megvan Angster Erzsébettől és Kertész Lászlótól a Turbo Pascal 6.0 című könyvem is valahol.
34

Kisfiú! Én a munkahelyemen

H.Z. · 2013. Szep. 14. (Szo), 09.46
Kisfiú! Én a munkahelyemen találkoztam először Turbo Pascallal. Az első, aminek a verzióját is megjegyeztem, az az 5.5 volt. És kb. ez volt az utolsó, amit használtam is valamire. :)
36

Több időt eltölt a

Joó Ádám · 2013. Szep. 14. (Szo), 12.35
Több időt eltölt a megtanulásával, mint keres egy ősrégi DOS-os "IDE"-t. Pl. nekem a Turbo Pascal 6.0 megvan még (van itt valaki olyan "öreg", aki ismeri?), és a WinXP cmd.exe-je alatt is műxik. Felmásolod egy pandrive-ra és viszed az "IDE"-t az érettségire is.


Igen, egy ilyen környezet volt az, ami miatt meggyűlöltem a Pascalt. Pedig nem a nyelvvel volt a baj, hanem a konstans wtf érzéssel.

Ha már Pascal, akkor valami ősi, de nem parancssoros fordító, nem tud mit kezdeni a hibaüzikkel,ha egyáltalán vannak.


?

De ma már nem lennék meglepve, ha nem Pascal menne


Az megy.

Ja, és gondolom nem ez az egyetlen, amiből le szeretne érettségizni...


Ez a kurva popszakma már csak ilyen.
37

Inkább óvakodjon attól a

bamegakapa · 2013. Szep. 14. (Szo), 13.03
Inkább óvakodjon attól a "remek" IDE-től... persze én is azon tanultam, de nem kívánom senkinek.

A linux-szal legalább megy valamire, olyan tudás, amit aztán remekül fog tudni hasznosítani. Ha már vihet pendrájvot az érettségire, akkor ennyi erővel egy livecd-t is készíthet.
39

Ha már vihet pendrájvot az

Joó Ádám · 2013. Szep. 14. (Szo), 18.25
Ha már vihet pendrájvot az érettségire, akkor ennyi erővel egy livecd-t is készíthet.


Szögezzük le, hogy ilyet nem lehet, mielőtt még valaki tényleg beállítana érettségire bármilyen adathordozóval.
38

Felmásolod egy pandrive-ra és

Joó Ádám · 2013. Szep. 14. (Szo), 18.24
Felmásolod egy pandrive-ra és viszed az "IDE"-t az érettségire is.


Ilyen természetesen nincs, egy listáról választhatsz operációs rendszert, nyelvet és fejlesztőkörnyezetet.
41

Nekem nem annyira természetes...

Pepita · 2013. Szep. 14. (Szo), 23.47
Ilyen természetesen nincs

Elnézést, de én '92-ben érettségiztem, utaltam is erre, hogy nem tudom, mi van a mai érettségin... Annyit tudok, hogy már '94-ben egész más szabályok voltak.

A Linuxnak - kizárólag az érettségi szempontjából - továbbra sem látom értelmét, persze hasznos beletanulni, ugyanúgy, mint úszni tudni is hasznos, de azt gondolom, hogy itt az elérhető eredmény és a befektetett idő/energia a fontos. Kérdéses is - úgy látom te tisztában vagy vele -, hogy az adott lista most elérhető-e (gondolom igen), és abban szerepel-e a kívánatos rendszer, stb. Ezzel együtt - szerintem - a Linuxra bőven ráér főiskolán / egyetemen, ha ebbe az irányba megy, akkor ott úgyis kötelező lesz.
Azt viszont hallom jónéhány ismerőstől, hogy a mostani érettségizőknek semmire sincs idejük, ha jól akarnak felkészülni. Emiatt én a helyében hanyagolnám egyelőre a Linuxot, nem az a feladat.
42

Egyébként nem tudom, manapság

bamegakapa · 2013. Szep. 15. (V), 00.12
Egyébként nem tudom, manapság hogy van, de 2001-ben még egy röhej volt a számítástechnika érettségi. Total Commanderben kellett fájlokat másolnom, vagy valami ilyesmi, kb 1-2 percig tartott az egész.

Mondjuk az egész érettségi röhej volt :).
44

Ez közép vagy emelt szint

Joó Ádám · 2013. Szep. 15. (V), 00.30
Ez közép vagy emelt szint volt?
47

Akkor még nem volt ilyesmi

bamegakapa · 2013. Szep. 15. (V), 02.35
Akkor még nem volt ilyesmi :).
48

Tényleg :)

Joó Ádám · 2013. Szep. 15. (V), 02.51
Tényleg :)
45

A lista minden évben előre

Joó Ádám · 2013. Szep. 15. (V), 00.40
A lista minden évben előre közzé van téve.

Ami a Linuxot illeti: egy Ubuntu használata semmivel sem igényel több tanulást, mint Mac-re, Androidra vagy bármi másra váltani. A lényeg az, hogy ne a vizsgán csodálkozzon rá a Unity-ra.

Ezen felül az alapvető parancssori készségeket sajátítsa el, ez nem igényel többet egy-két nap gyakorlásnál.

Cserébe egy sokkal egyszerűbb és sokkal megbízhatóbb fejlesztői környezetet kap, mint ha egy windows-os IDE-t, vagy a helyi rendszergazda által felhúzott Cygwint használná.
46

Lassan meg lesz :)

Pepita · 2013. Szep. 15. (V), 02.08
Ami a Linuxot illeti: egy Ubuntu használata semmivel sem igényel több tanulást, mint Mac-re, Androidra vagy bármi másra váltani.
Ez azt jelenti, hogy nem vizsgázhat Windowson?

Én ebből az egy szempontból vitatom másik oprendszer tanulását, mivel valamelyik win-t biztosan használja. Csak időt spórolnék neki.

IDE-ről nem vitatkozom: én használok, win alatt, pont.

De ismered programozni-tanulásról is a véleményem: első helyen assembly. Ha ott nem vérzik el (nem adja fel, továbbjut a Hello world-ön: mondjuk egy bitképet fájlból ki tud rajzolni a képernyőre), akkor jöhet következő nyelv. Assembly-hez aztán tényleg csak árt egy IDE, nem is tudom létezik-e hozzá.
49

Ez azt jelenti, hogy nem

Joó Ádám · 2013. Szep. 15. (V), 03.01
Ez azt jelenti, hogy nem vizsgázhat Windowson?


Nem, természetesen vizsgázhat Windows-on, a legtöbben azon vizsgáznak. Az én véleményem azonban az, hogy a legkönnyebben használható, zéró-konfigurációs fejlesztői környezetet egy Linux adja.

Az, hogy érdemes-e IDE-t használni, az preferencia kérdése, én nem szeretem őket, más igen. Itt azonban egy kezdőről és egy vizsgáról van szó, egy IDE pedig csak még egy dolog, amit oda-vissza ki kellene ismerjen, márpedig ez nem fog menni. Tapasztalatból beszélek, nekem ugyanis eddig még nem volt olyan tanítványom, aki ne küzdött volna az IDE-vel (ezoterikus hibák, linkelési bizonytalanságok sít.), amihez minden jobb belátásra térítési kísérletem ellenére úgy ragaszkodott.
50

IDE (oda)

Pepita · 2013. Szep. 15. (V), 06.20
egy IDE pedig csak még egy dolog, amit oda-vissza ki kellene ismerjen
Pontosan. Ugyanúgy, mint egy számára új oprendszert. Csak az előbbi sok gyorsaságot ad(hat) a fejlesztéshez, míg a Linux - az ő szemével nézve - nem ad semmit. Ha még mindig Pascalról beszélünk, mint javasolt vizsganyelv, akkor semmit nem kell Windowson konfigolni, de IDE sem kell.

Ha valaki ragaszkodik az IDE-hez, annak komoly oka van. A tanulónál is (pl. nem jól jegyez meg fv-neveket, kattintani jobban szeret, mint gépelni, stb). Ha a konzolt akarod ráerőltetni, min. ugyanolyan küzdelmes lesz neki, nem biztos, hogy sikerrel jár(sz).
(Én pl. adott feladatra egy bizonyos IDE-hez ragaszkodom, még verziót is csak akkor váltok, ha nagyon muszáj. Persze megnézek másokat is, de magával a beletanulással nem töltök sok időt. Épp csak ellenőrzöm néha, hogy lehet-e nekem jobb, mint amit használok.)

Mondom mindezt úgy, hogy nem vagyok tanár.

Szerk.: Kiindultunk onnan, hogy a PHP-t akarta magyarra fordítani... Ne ijesszük már el ennyire, lehet nem is tudja, miről vitázunk, a végén még nem megy érettségizni.
51

A legtöbb IDE - amit idáig

inf3rno · 2013. Szep. 15. (V), 10.51
A legtöbb IDE - amit idáig láttam - java-ra épül, ami meg platform független, szóval a platformból körülbelül annyit kell megtanulni, hogy hogyan kell elindítani az IDE-t, illetve megnézni a végeredményt, plusz még esetleg a unit teszteket futtatni, bár az szerintem neki nem fog kelleni.

Én windows-on nőttem fel, és a fiatalok többsége is. Aki használt már DOS-t, az tudja, hogy kényelmetlen, emiatt a windows felhasználók között egyáltalán nem terjedt el a parancssor használata, helyette inkább GUI-ban, meg kattintásokban gondolkodunk. Azt elismerem, hogy a unix parancssor használata kényelmesebb, de szerintem egy jól megcsinált grafikus felülettel nem ér fel.

Az IDE-vel én sosem küzdöttem, rengeteg kényelmi funkció van benne, ami egy notepad-ben nincsen, a notepad++, stb... felpluginezés meg szerintem időpazarlás, amikor megkapom ugyanazt, vagy jobbat egyben, és sokszor jobb minőségben. Az IDE-t meg kell tanulni használni. Amíg fogalma sincs valakinek, hogy mit jelent pl az, hogy refactor, vagy code reformat, stb... Addig persze nincs értelme, és csak zavaró. Én pl nem használok valami sok extra feature-t rendszeresen: run unit test, code coverage, code reformat, refactor típusok, go to declaration, find all occurence, replace all occurence, git parancsok, ennyi. Kb 20-30 alapvető dolgot kell megtanulni, hogy hatékonyan lehessen használni egy IDE-t, onnantól viszont, hogy tudja használni, senki nem akar notepad-re visszatérni, mert lassú és kényelmetlen...
58

+1

Pepita · 2013. Szep. 15. (V), 17.28
Azért a notepad++ apró javításra / belenyúlásra (pl. php.ini, stb) jó lehet, vagy kimenetellenőrzésre, ezek miatt (ha nem fut) én nem indítok el IDE-t, így gyorsabb. De nagyon vártam a véleményed, tudtam, hogy sok dologban hasonló lesz. (Én ma is "megrögzött" windowsos vagyok. :))
20

Kérdés, hogy tanítanak-e neki

Joó Ádám · 2013. Szep. 11. (Sze), 14.34
Kérdés, hogy tanítanak-e neki valamit... :)


Igen nagy hülyeség úgy nekivágni az érettséginek egy tárgyból, hogy nem jársz belőle fakultációra.

Van olyan könyv ami jó is és nem a tipikus régi módszer szerint próbálkozik?


Milyen a tipikus régi módszer?
25

Üdvözlöm Bob autóalkatrész

hunkris · 2013. Szep. 11. (Sze), 17.58
Üdvözlöm Bob autóalkatrész kereskedő weboldalán. :DD
26

?

Joó Ádám · 2013. Szep. 12. (Cs), 04.16
?
27

PHP

H.Z. · 2013. Szep. 12. (Cs), 09.52
PHP tankönyv.
http://www.perfactkiado.hu/phpesmysql.php
(ezt dobta fel elsőnek a google)
Elindulni jó, de összességében én nem voltam teljesen elégedett vele. Főleg azért, mert nem igazán (nem eléggé?) OOP központú.
28

Régen jó volt a könyv. Nekem

hunkris · 2013. Szep. 12. (Cs), 16.01
Régen jó volt a könyv. Nekem is megvan, viszont ma már nem ajánlanám megvételre, mivel nem támogatott függvényeket használnak benne (pl: get_magic_quotes_gpc), és tényleg nem eléggé OOP, gyakorlatilag egy fejezben bontogatják az alapokat, aztán bumm.
29

Én tavaly v. tavalyelőtt

H.Z. · 2013. Szep. 12. (Cs), 16.17
Én tavaly v. tavalyelőtt vettem és elég gyorsan leraktam. :(
30

Vannak nagyon jó könyvek, de

inf3rno · 2013. Szep. 12. (Cs), 22.04
Vannak nagyon jó könyvek, de szinte minden fent van a neten cikkekben, ami ezekben található. Talán annyi előnye van a könyvnek, hogy valamivel összeszedettem, viszont egy témában minimum 2-3 jó könyvet érdemes elolvasni, mert nem lehet tudni, hogy biztosan a legmagasabb színvonalút választottuk e ki. A cikkeknél általában én megnyitok egy témában legalább 100-at, aztán formálódik a kép, hogy merre tovább...
52

és tényleg nem eléggé OOPÉs

Hidvégi Gábor · 2013. Szep. 15. (V), 13.45
és tényleg nem eléggé OOP
És akkor mi van? OOP nélkül is lehet kiváló programokat készíteni, pl. Linuxon rengeteg szoftvert és rutinkönyvtárat C-ben írnak. A Gyűrűk Verséből az alábbi sor jutott eszembe: "bilincs az egyetlen", továbbá a Szivárgó absztrakciók törvénye.
53

Az van, hogy mostanában

H.Z. · 2013. Szep. 15. (V), 14.09
Az van, hogy mostanában szinte minden hirdetésben OOP szemlélet az elvárás és én is ezen az úton akartam elindulni, mert nem a PHP volt számomra az elérendő cél, az csak egy szükséges rossz lett volna. :)

ui: a linked több mint tíz éves.
54

Több mint ezer éves

Hidvégi Gábor · 2013. Szep. 15. (V), 14.27
Több mint ezer éves link.

mostanában szinte minden hirdetésben OOP szemlélet az elvárás
Erről beszélek: bilincsbe köt az egyetlen. Azaz mások hozzák meg helyetted a döntéseket, utána meg csodálkozol, hogy nem a te elképzeléseidnek megfelelően alakul a sorsod.

Mondok egy példát: én az angol érettségin, az angol és német nyelvvizsgák szóbelijének beszélgetős részén mindhárom alkalommal ugyanarról a témáról beszéltem, pedig más-mást húztam. Azért tettem így, mert ahhoz volt kedvem.

Ezek a cégek azt várják el, hogy kalapáccsal oldj meg minden feladatot. Persze, ismerni kell a kalapács használatát, de ha te tudsz hatékonyabb eszközről, akkor úgy kell alakítani a dolgokat, hogy azt használhasd minél hamarabb.
55

Valamit félreértelmezel. Hogy

H.Z. · 2013. Szep. 15. (V), 15.01
Valamit félreértelmezel. Hogy elvárás az OOP ismeret, még nem jelenti azt, hogy mindenre használni kell. Viszont a legtöbb esetben, feltéve, hogy olyan fogalmazza a hirdetést, aki ért is az adott területhez, nem azért teszik bele az OOP kitételt, mert divatos.
A másik meg: az én szempontomból mindegy, hogy csak divat vagy valóban haszna van, ha egyszer elvárják és interjún esetleg bele is kérdeznek.
56

feltéve, hogy olyan

Hidvégi Gábor · 2013. Szep. 15. (V), 15.31
feltéve, hogy olyan fogalmazza a hirdetést, aki ért is az adott területhez
Feltéve... máris egy bizonytalan tényező. Lehet, hogy csak HR-es, és már hallotta valahol a kifejezést. Egy átlag website-hoz, mint például az Origo, miért van szükség OOP-re? Kapsz egy url-t, kikeresed az adatbázisban a hozzá tartozó címet, dátumot, szerzőt, bevezetést és szöveget, majd beteszed a megfelelő HTML sablonba. Itt mit akarsz és ki elől elrejteni? Minek kell örökölnie micsodát?
57

Az erős statikus típusosság

Joó Ádám · 2013. Szep. 15. (V), 15.47
Az erős statikus típusosság segít, hogy hibamentes kódot írj. Új, az alkalmazáshoz illeszkedő típusokat a legtöbb nyelvben osztályok képében hozol létre.

Én a HTML kimenetet programozottan állítom elő: Az XML NodeList, Element és Text osztályok mind a Node interfészt valósítják meg; az Element örökli a viselkedését a NodeList-től; ők mind, és a HTTP válasz megvalósítják a Serializable interfészt. A Layout osztályom örököl Element-től, az egyes oldalakhoz tartozó sablonok örökölnek a Layout-tól.

Gábor, neked nem az OOP-vel van bajod, ami 50 éve létező programozási paradigmák egy összefoglaló neve; hanem az adattípusokkal. Ez viszont elég nagy baj.
59

Azért tegyük hozzá

Pepita · 2013. Szep. 15. (V), 17.47
- ha már PHP könyvön indult a szál -, hogy a PHP nem a legalkalmasabb nyelv OOP megvalósítására, pont azért, mert - ha van hajlandóságod - neked kell külön programoznod ahhoz, hogy valami típusos legyen. Én lennék a legboldoggabb, ha a PHP erősen típusos lenne...
Gábor, neked nem az OOP-vel van bajod, ... hanem az adattípusokkal.
Ez szerintem nem így van, kérlek indokold és / vagy vitassátok meg, kíváncsi vagyok!
Szerintem Gábornak épp az öröklődéssel, származtatással, stb. van "gondja", ami - valljuk be - valamennyivel mindig lassabb futásidőt eredményez, mint egy fv-gyűjtemény, de ez a legtöbb esetben nem észrevehető különbség. PHP-ban nem tudom (mert szkript nyelv), de egyes nyelvekben a memóriahasználat sokkal nagyobb az objektumok helyes használata nélkül, mert sok statikus változóra / függvényre van szükséged, az osztályt meg - ha nincs szükséged már rá - simán kidobod, és csak az eredményt tartod meg.
Ezzel kapcsolatban: a PHP fordítója a feldolgozás / futtatás során felszabadítja azoknak a változóknak a területét, amelyik null értéket kap? Ha igen, akkor kb ugyanaz a helyzet: ezért is érdemes valamennyire OOP.
61

Szerintem Gábornak épp az

inf3rno · 2013. Szep. 15. (V), 23.40
Szerintem Gábornak épp az öröklődéssel, származtatással, stb. van "gondja", ami - valljuk be - valamennyivel mindig lassabb futásidőt eredményez, mint egy fv-gyűjtemény, de ez a legtöbb esetben nem észrevehető különbség.


Én csak a szokásos dumával tudok jönni, hogy először kódolni kell, utána optimalizálni. :-) Azt mondják, hogy nem ez szokott lenni a szűk keresztmetszet, hanem a hálózati kapcsolat, fájlrendszer, adatbázis, stb... (Még sosem próbáltam ki, hogy igazuk van e.)
62

Dolgoztam már sok

Hidvégi Gábor · 2013. Szep. 16. (H), 08.27
Dolgoztam már sok kisebb-nagyobb projekten, és mivel nap mint nap látom, hogy OOP így, OOP úgy, mindig elgondolkoztam rajta, hogy ha már ennyire reklámozzák, hol tudnám én is bevezetni. De aztán feltettem a kérdést: ki elől szeretnék elzárni és mit? Aki hozzáfér a forráskódhoz, úgyis azt ír át, amit akar, legfeljebb külső API-k esetében van értelme, hogy nem osztom meg az összes tulajdonságot és függvényt. Öröklődés, polimorfizmus? Valószínűleg túl primitív munkáim voltak eddig, de egyszerűen nem láttam értelmét ilyenekkel elbonyolítani a kódot.
66

Pedig kényelmesebb is

Pepita · 2013. Szep. 16. (H), 23.19
Amint beleszoksz (vagy belekényszerülsz) egy kicsit, rögtön vagy nagyon hamar meglátod a kényelmet is benne, hogy "ez ezé, az azé". És csak azt adom át, amit muszáj. Ha van egy jól megírt osztályod, oda viszed, ahova akarod (köv. projektekbe). Míg a függvénytáraddal változók tömkelegét kell kezelned, és fejben is tartanod, mert globálisak. Sokkal egyszerűbb egy osztály 20 tulajdonsággal és 20 fv-el egyetlen változóban, mint össz. 40 fejben tartandó globális valami. Nem beszélve itt is az osztályon belül megvalósítható ellenőrzésekről, átalakításokról, amiket egyszer automatizálsz, többé nincs dolgod vele.
Sokkal átláthatóbb kód, még akkor is, ha öröklődéssel, stb. "nem bonyolítod".

Gábor, rosszul tudom, hogy te Delphiben is kódoltál? Onnét olyan OOP-rálátásodnak kéne lenni, hogy ihaj. Kivéve, ha csak console-appot írtál. De ott is ajánlott, kényelmi szempontból.
75

Használtam Delphit, pontosan

Hidvégi Gábor · 2013. Szep. 17. (K), 07.16
Használtam Delphit, pontosan tudom, mi az OOP, de nem győzött meg. PHP-ban és JS-ben legalább van választási lehetőségem, hogy hogyan programozzak.
78

Miért?

Pepita · 2013. Szep. 17. (K), 09.26
de nem győzött meg
Miért?

PHP-ban és JS-ben legalább van választási lehetőségem
Igen, két rossz: a nemigazán OOP és a spagetti (na jó, legyen össze-vissza include-olt fv-tár) közül...
87

Olvass el egy jó design

BlaZe · 2013. Szep. 29. (V), 08.51
Olvass el egy jó design pattern könyvet és szerintem akkor megérted miért olyan "divatos". Egy lényege a hordozhatóság, illetve az adatok elerejtése (bármennyire is mondod, hogy ennek nincs értelme, van). De az igazi előnye ott jön ki, amikor refaktorálni kell. Egy jól szervezett OOP kódban egy refaktor jóval kisebb kódmennyiséget érint, mint egy struktúrált kódban. Az áttekinthetőségéről nem is beszélve.
89

Tudsz ajánlani olyan

Hidvégi Gábor · 2013. Szep. 29. (V), 14.45
Tudsz ajánlani olyan könyvet/website-ot, ahol az állításaidat alátámasztják? Esetleg tudnád saját példákkal illusztrálni?
Azaz:
- mitől lesz hordozhatóbb egy OOP kód, mint egy procedurális?
- milyen előnyökkel jár az adatok elrejtése?
- ki elől és miért akarnék én bármit is elrejteni?
- mitől lesz könnyebb refaktorálni az OOP kódot?
- miért érint jóval kisebb kódmennyiséget a refaktorálás OOP kódnál?
- mitől lesz az OOP kód áttekinthetőbb?

Úgy lehetne viszonylag könnyen ezekre a kérdésekre választ kapni, ha definiálnánk egy feladatot, lefejlesztenénk OOP és procedurális megközelítéssel, és összehasonlítanánk a két megoldást.
91

Bár a kérdés nem nekem szólt,

MadBence · 2013. Szep. 29. (V), 15.34
Bár a kérdés nem nekem szólt, azért megpróbálok pár kérdésre válaszolni:

Meglepő, de az adatokat a programozó leginkább saját maga elől rejti el. Méghozzá jó indokkal:
Amikor objektumokkal dolgozunk, akkor egy olyan absztrakciós réteget készítünk, ami eltakarja a konkrét implementációt (ezáltal függetlenedünk tőle, azaz a kód újrafelhasználható lesz).
Tegyük fel, hogy van egy lista adatszerkezetünk, amit egy egyszerű tömbként valósítunk meg. Elrejtjük ezt a belső reprezentációt, csak egy iterátoron keresztül lehet a tartalmához hozzáférni.
Idő közben rájöttünk, hogy a tömb nem megfelelő, láncolt listára van szükségünk. Mit teszünk? Átírjuk magát az implementációt, illetve az iterátor (implementációját), és készen vagyunk, az alkalmazás többi része észre sem veszi, hogy változott valami.
Mi történt volna, ha a tömbhöz közvetlenül hozzáférünk? Át kell nézni az egész alkalmazás kódját, és ahol ezt a listát használjuk, ott módosítani kell a hozzáférésen. Ez nagyságrendekkel nehezebb (több kód, több hibalehetőség, duplikáció, stb).

Tehát ezért előnyös az információk (az implementáció) elrejtése, ezért lesz könnyebb refaktorálni a kódot (ezért érint kevesebb kódmennyiséget a refaktorálás).
Az áttekinthetőség pedig azért jobb, mert OO környezetben az adat, és a rajta végezhető művelet együtt van (kódszervezés szempontjából is), maga a való élet is egy OO környezet, az absztrakciók pedig kitisztítják a problémát, elrejtik a probléma szempontjából irreleváns dolgokat.

Az OOP nem a szent grál, amint a példa is mutatja.
92

mitől lesz hordozhatóbb egy

Joó Ádám · 2013. Szep. 29. (V), 15.37
mitől lesz hordozhatóbb egy OOP kód, mint egy procedurális?


Attól, hogy jól definiált interfészeket használsz. (Vö.: Mitől lesz hordozhatóbb a procedurális kód, mint strukturálatlan?)

milyen előnyökkel jár az adatok elrejtése?


Az implementáció az interfésztől függetlenül változhat. (Vö.: Milyen előnyökkel jár a függvénytörzs elrejtése?)

ki elől és miért akarnék én bármit is elrejteni?


Mert azzal, hogy bizonyos dolgokat elrejtesz, és csak egy interfészt teszel nyilvánossá, azzal biztosítod azt, hogy egyrészt a kódod felhasználói ne támaszkodjanak olyan implementációs részletekre, amik bármikor változhatnak, másrészt pedig azt, hogy egy adatstruktúrád belső állapota konzisztens maradjon.

mitől lesz könnyebb refaktorálni az OOP kódot?


Mert jól definiált interfészeket használsz. (Vö.: Mitől lesz könnyebb refaktorálni a procedurális kódot, mint a strukturálatlant?)

miért érint jóval kisebb kódmennyiséget a refaktorálás OOP kódnál?


Mert jól definiált interfészeket használsz. (Vö.: Miért érint jóval kisebb kódmennyiséget a refaktorálás procedurális kódnál, mint strukturálatlannál?)

mitől lesz az OOP kód áttekinthetőbb?


Mert jól definiált interfészeket használsz. (Vö.: Mitől lesz a procedurális kód áttekinthetőbb, mint a strukturálatlan?)

Remélem sikerült megvilágítani a gondot a kérdéseiddel. Az objektumorientáltság egy összefoglaló név különböző programozási gyakorlatokra, amiknek a nagy részét te is használod. Természetesen az interfészeken túl a polimorfizmus is segít a kód modulárisabbá tételében, a származtatás pedig segít benne, hogy kevesebb felesleges kódot írj. És persze az egész alkalmazás-specifikus típusok létrehozásán alapul. Ezek közül kizárólag a dinamikus polimorfizmus az, ami az objektumorientáltság újdonsága – ha lehet ezt mondani egy 1967-ben, tehát 56 éve (!) bevezetett eszközre. Az, hogy a legtöbb nyelv ehhez egy speciális szintakszist rendel, illetve például a PHP-ban ezen szintakszis bevezetése előtt nem is volt lehetőséged például absztrakt adattípusokat létrehozni, már egy más kérdés. C-ben is simán lehet objektumorientáltan programozni, csak nem túl kényelmes.

Az a baj, hogy belekapaszkodsz szavakba („OOP”, „statikus”), amik ellenszenvesek, és nem gondolsz utána, mit takarnak, mert akkor te is rájönnél, hogy ezek jó dolgok, amiket magad is használsz.
94

»mitől lesz hordozhatóbb egy

Hidvégi Gábor · 2013. Szep. 29. (V), 17.19
»mitől lesz hordozhatóbb egy OOP kód, mint egy procedurális?«
Attól, hogy jól definiált interfészeket használsz. (Vö.: Mitől lesz hordozhatóbb a procedurális kód, mint strukturálatlan?)
A példáid nem a legjobbak:
1, procedurális programozásban is definiálsz interfészeket (vö. function függvény(paraméter1, paraméter2) és objektum.obj_metódus(paraméter1, paraméter2))
2, az OOP és a procedurális programozás is strukturált

»ki elől és miért akarnék én bármit is elrejteni?«
Mert azzal, hogy bizonyos dolgokat elrejtesz, és csak egy interfészt teszel nyilvánossá, azzal biztosítod azt, hogy egyrészt a kódod felhasználói ne támaszkodjanak olyan implementációs részletekre, amik bármikor változhatnak
A programom felhasználói hozzáférnek a kódhoz, és bármikor átírhatják (és át is írják) a private-ot public-ra, ha a szükség úgy hozza.

»mitől lesz könnyebb refaktorálni az OOP kódot?«
Mert jól definiált interfészeket használsz.
A függvények is jól definiáltak.

Az a baj, hogy belekapaszkodsz szavakba („OOP”, „statikus”), amik ellenszenvesek, és nem gondolsz utána, mit takarnak
Igen, ez így van, de pont, hogy belegondolok. Utánajártam az elméletnek, én eddig a saját programozási projektjeimet félig strukturálatlanul készítettem el, és tökéletesen működnek. Nincs semmilyen adattípus beleégetve a kódba, hanem gyakorlatilag az adatbázisból egy minimális php kódon keresztül megy ki minden HTML-be. Egyedül az adminisztrációs felületen van ellenőrizve, hogy milyen adatokat visznek fel, ahol szükséges, de ettől függetlenül a kód végtelenül egyszerű – és ez a séma a website-ok túlnyomó többségére biztosan ráhúzható. Nincs adatrejtés, nincs öröklődés, nincs polimorfizmus.
95

procedurális programozásban

Joó Ádám · 2013. Szep. 29. (V), 17.38
procedurális programozásban is definiálsz interfészeket


A függvények is jól definiáltak.


Akkor még mindig nem érted, mit próbálok mondani. Épp arról beszélek, hogy részben te is OOP-t használsz, mert az OOP egyik alappilére az iterfészek definiálása, amik a gyakorlatban függvényeket jelentenek.

A programom felhasználói hozzáférnek a kódhoz, és bármikor átírhatják (és át is írják) a private-ot public-ra, ha a szükség úgy hozza.


Az már az ő bajuk. Te dokumentáltad a forráskódban a hozzáférési szabállyal, hogy mi az, amire támaszkodhatnak és mi az, amire nem. Ha ők módosítják a kódod, és ezért a sajátjuk nem fog működni, amikor te kiadod a következő verziót, vagy simán csak rosszul fog működni a kódod, mert nem az interfészen keresztül használják, akkor magukra vessenek. Az adatrejtés csupán a nyilvános interfészt, és a nem nyilvánosnak szánt implementációt dokumentálja, és a fordító által ki is kényszeríti, hogy véletlen ne szeghesd meg a megállapodást. Pont mint a statikus típusrendszer teszi a kifejezések által felvehető értékekkel.

Utánajártam az elméletnek, én eddig a saját programozási projektjeimet félig strukturálatlanul készítettem el, és tökéletesen működnek.


Nehezen hiszem, hogy ezekben ne használnál feltételvizsgálatot és ciklusokat.

Nincs semmilyen adattípus beleégetve a kódba, hanem gyakorlatilag az adatbázisból egy minimális php kódon keresztül megy ki minden HTML-be.


Tehát csak bájtsorozatokat használsz? Mert ha már legalább kétféle adattípust használsz, mondjuk számokat is, akkor nem igaz, amit írsz, épp csak a kész adattípusokat használod, de használod őket.

A kimenő HTML-t sem érdemes sztringként kezelni, mert így elkerülhető, hogy rosszul formázott legyen. Az adminfelületen, ha használsz valamilyen markupot, akkor azt sem célszerű sztringfüggvényekkel ellenőrizgetni, helyette felparzolod egy saját típusba, és egy struktúrát ellenőrzöl.

Egyedül az adminisztrációs felületen van ellenőrizve, hogy milyen adatokat visznek fel, ahol szükséges, de ettől függetlenül a kód végtelenül egyszerű – és ez a séma a website-ok túlnyomó többségére biztosan ráhúzható.


Egy végtelenül egyszerű megoldás működhet egy végtelenül egyszerű alkalmazásnál. De egész biztos, hogy a website-ok túlnyomó többségére ez már nem húzható rá. Én azt sem értem, hogy miért gondolod úgy, hogy egy webalkalmazás bármivel is kevésbé komplex mint bármilyen más szoftver. Attól, hogy egy kérés-válasz alapú protokollon keresztül, szerializált formátumban kommunikálsz vele, ugyanúgy működik, mint egy asztali alkalmazás.
104

Úgy gondolom, hogy értem,

Hidvégi Gábor · 2013. Szep. 29. (V), 20.33
Úgy gondolom, hogy értem, amit írsz. Ami ellen kifogásom van, hogy ha az OOP eszköztárát, szintaktikáját használod (osztályok, interface, öröklődés), akkor egy csövön keresztül modellezed a világot. Vannak alternatívák, szerintem jobb a procedurális megközelítés, mert lehetőséget ad arra, hogy bizonyos adatok és bizonyos függvények között ne legyen olyan erős a kapcsolat, azaz laza kötéssel dolgozzak.

Nehezen hiszem, hogy ezekben ne használnál feltételvizsgálatot és ciklusokat
- számomra a félig strukturálatlan kód definíciójába ezek és a függvényhívások beletartoznak.

Tehát csak bájtsorozatokat használsz?
Karakterláncokat és számokat. Néha booleant.

A kimenő HTML-t sem érdemes sztringként kezelni, mert így elkerülhető, hogy rosszul formázott legyen.
Eddig mindig stringként kezeltem, és soha nem volt belőle gond.

Én azt sem értem, hogy miért gondolod úgy, hogy egy webalkalmazás bármivel is kevésbé komplex mint bármilyen más szoftver.
A szoftver olyan komplex, amilyenre megírják. Már jópár éve egy eléggé összetett webes alkalmazáson dolgozom, amiben csak azért vannak objektumok, mert az elődöm abban kezdte az egészet, egyébként mind singletonként működik, nincs öröklés, azaz egy az egyben megfelel egy procedurális kódnak. Az adatok teljesen függetlenek a felülettől, ez biztosítja, hogy nagyon egyszerű a működés, mégis összetett üzleti folyamatokat kezelünk. Tehát lehetséges a dolog.
108

szerintem jobb a procedurális

Joó Ádám · 2013. Szep. 29. (V), 21.24
szerintem jobb a procedurális megközelítés, mert lehetőséget ad arra, hogy bizonyos adatok és bizonyos függvények között ne legyen olyan erős a kapcsolat, azaz laza kötéssel dolgozzak


Erre tudsz hozni egy példát?

számomra a félig strukturálatlan kód definíciójába ezek és a függvényhívások beletartoznak.


Ezt nem értem, a strukturált programozás éppen ezeknek a használatáról szól, mitől lesz a kódod csak félig strukturált?

Karakterláncokat és számokat. Néha booleant.


Meg asszociatív tömböket, meg erőforrásokat, meg nullt. Ezekben semmi speciális nincs, ezek adattípusok. Épp csak a PHP fejlesztői ezeket implementálták a nyelv részeként. Nem értem, hogy ha szükségét érzed, hogy ne csak sztringet használj, hanem dedikált típusokat, akkor miért csak a beépítetteket érzed hasznosnak.

A szoftver olyan komplex, amilyenre megírják.


A szoftver legalább olyan komplex, amilyen komplexek a követelményei.

Az adatok teljesen függetlenek a felülettől, ez biztosítja, hogy nagyon egyszerű a működés, mégis összetett üzleti folyamatokat kezelünk. Tehát lehetséges a dolog.


Senki sem vonja kétségbe, hogy lehetséges, csak azt, hogy ez a leghatékonyabb módja. De én még csak nem is erről beszélek, én továbbra is azt akarom elhitetni veled, hogy az OOP és a procedurális programozás nem két egymással ellentétes paradigma, hanem előbbi az utóbbi egy bizonyos felhasználási mintája.
119

Az oop a struktúrális

inf3rno · 2013. Szep. 30. (H), 00.53
Az oop a struktúrális programozás továbbfejlesztése kényelmi funkciókkal, best practice-ekkel. Ez hasonló vita, mint az, hogy használjunk e keretrendszert, vagy sem. Nyilván használjunk, mert ötödére csökkenti a fejlesztési időt. Nyilván oo kódot is azért írunk, mert az szintén csökkenti a fejlesztési időt.
140

»szerintem jobb a

Hidvégi Gábor · 2013. Szep. 30. (H), 09.25
»szerintem jobb a procedurális megközelítés, mert lehetőséget ad arra, hogy bizonyos adatok és bizonyos függvények között ne legyen olyan erős a kapcsolat, azaz laza kötéssel dolgozzak«
Erre tudsz hozni egy példát?
Az általunk fejlesztett szoftverben először az ExtJS első verzióját kezdtük el használni, amit kifejezetten alkalmazásfejlesztésre találtak ki. Amíg Móricka-egyszerűségű űrlapokkal játszottunk, nem is volt gond, de amint a valós kéréseknek kellett megfelelni, borult az egész, mert olyan lassú lett. A példa a kedvencem, a kombobox, ami hétszeres öröklési osztályon keresztül készül el: objektum -> Observable (eseménykezelők) -> Component -> Field -> TextField -> TriggerField -> ComboBox, összesen körülbelül nyolcszáz soros kód, plusz a mellékhajtások, mint pl. az AJAX kérés kezelése, adatokkal való feltöltés. Ebből a komponensből kellett nekünk elhelyezni egy helyen százötvenet, amire a böngésző úgy reagált, hogy egymás után kétszer bedobta a "Script nem reagál, leállítja a futását?" című kérdést, mire elkészült a feladattal.

Emiatt, valamint amiatt, hogy nehézkes volt a hibajavítása és a bővítése, átírtam az egészet. Kidobtam az öröklődést meg minden egyéb OOP sallangot, és lett belőle egy nettó kétszázötven soros kód saját eseménykezeléssel meg mindennel, és az ablakunk egy szemvillanásnyi idő alatt jelenik meg. Ha OOP szintakszissal dolgozol (öröklődés, polimorfizmus), mindent objektumként fogsz fel, azaz kalapács van a kezedben, és mindent szögnek látsz.

Másik példának mondjuk vegyünk egy számlát: két részből áll, egy fejlécből és tételsorokból. OOP megközelítésben így néz ki a definíciója:
class Tételsorok($szamla_sorszam) {
}
class Számla() {
  private $tetelsorok;
function __construct() {
  $this->tetelsorok = new Tételsorok($this->sorszam);
}
}

Ahhoz, hogy a tételsorokhoz hozzáférj, a számlát példányosítani kell. De mi van akkor, ha neked csak bizonyos tételsorok adataira van szükséged a statisztikához, mondjuk azokra, amelyeknél a termék darabszáma nagyobb, mint tíz? Ha megszűnteted az erős kapcsolatot a számla és a tételsorok között, pont ugyanott vagy, mint procedurális, laza programozásnál, ahol csak végigiterálsz pár adattömbön, és kész, és az adatok közti összefüggést nem kezeled.

Nem értem, hogy ha szükségét érzed, hogy ne csak sztringet használj, hanem dedikált típusokat, akkor miért csak a beépítetteket érzed hasznosnak.
Mert alacsonyak az igényeim.

továbbra is azt akarom elhitetni veled, hogy az OOP és a procedurális programozás nem két egymással ellentétes paradigma, hanem előbbi az utóbbi egy bizonyos felhasználási mintája
Én pedig azt, hogy ha az OOP programozás a procedurális programozás részhalmaza, akkor célszerűbb procedurálisan programozni, mert ott van lehetőségem más közelítéssel dolgozni (pl. funkcionálisan), míg OOP szintaktikával csak egyféleképp oldhatom meg a feladatot.
142

A JavaScript (vagy bármilyen

Joó Ádám · 2013. Szep. 30. (H), 14.09
A JavaScript (vagy bármilyen más szkriptnyelv) rossz ellenérv az objektumorientáltság ellen, mert az egész, ahogy van erőforráspazarlás, a JavaScript ráadásul még az öröklést is dinamikusan csinálja. A hétszeres öröklés, amit felvázoltál, szerintem önmagában nem vészes, és egy statikus, fordított nyelvben százötven darab nevetségesen kis szám. És az is simán lehet, hogy egyszerűen csak rosszul van megírva az Ext.

Ahhoz, hogy a tételsorokhoz hozzáférj, a számlát példányosítani kell. De mi van akkor, ha neked csak bizonyos tételsorok adataira van szükséged a statisztikához, mondjuk azokra, amelyeknél a termék darabszáma nagyobb, mint tíz? Ha megszűnteted az erős kapcsolatot a számla és a tételsorok között, pont ugyanott vagy, mint procedurális, laza programozásnál, ahol csak végigiterálsz pár adattömbön, és kész, és az adatok közti összefüggést nem kezeled.


Ez mind a konkrét követelményektől függ, a fenti kódod pedig szinte semmit nem mond ezekről. De alapvetően semmi nem akadályoz meg benne, hogy csak tételsorokat hozzak létre, ha csak azoknak a funkcionalitására van szükségem. Osztályokat nem azért definiálsz, mert jó szórakozás, hanem mert új adattípust akarsz bevezetni hozzá tartozó műveletekkel. Az OOP nem overengineeringet jelent, még ha van is rá sok példa.

Mert alacsonyak az igényeim.


Azt tudod, hogy ugyanez egy szóban, fosztóképzővel megfogalmazva, már nem pozitív csengésű? :)

Én pedig azt, hogy ha az OOP programozás a procedurális programozás részhalmaza, akkor célszerűbb procedurálisan programozni, mert ott van lehetőségem más közelítéssel dolgozni (pl. funkcionálisan), míg OOP szintaktikával csak egyféleképp oldhatom meg a feladatot.


Biztos vagyok benne, hogy nem funkcionálisra gondoltál, mert a funkcionális programozás még erősebb megkötésekkel dolgozik, mint az objektumorientált. Ilyen megközelítéssel a legjobb volna assembly-ben dolgozni, mert ott semmilyen struktúrát nem kell vigyél a kódodba, teljes a szabadság. Véletlennek tartod, hogy nem így fejlesztünk? Minden egyes új paradigma elvesz a szabadságodból, mert az önfegyelem hosszú távon kifizetődőbb, mint a korlátlan szabadság. A strukturált kódban nem használsz goto-t, cserébe követhető a végrehajtás; az objektumorientált programozásban nem nyúlkálsz az adatszerkezetek belsejében, cserébe könnyebb módosítani a kódot; ha funkcionálisan programozol, a kódod nem használ változókat és nem ír/olvas, cserébe jól párhuzamosítható. Ha nem dohányzol, akkor megfosztod magad a nikotintól, cserébe nem nem vágják ki negyven évesen a gégéd.

Persze a fentiek közül egyik sem vallás: néha a goto olvashatóbbá teszi a kódot; nem kell minden adatot interfész mögött tárolni; sokszor a változó adattárolás hatékonyabb; néha jól esik egy szivar.
144

Jelenleg a 4-es verzió van

inf3rno · 2013. Szep. 30. (H), 17.59
Jelenleg a 4-es verzió van extjs-nél, és minden verzió váltásnál újraírták az egészet. Én a 3-asat próbáltam, nem voltam elégedett vele, szerintem rosszul tervezték, a 7x-es öröklődés helyett inkább a decorator pattern szokott a jellemző lenni gui-knál, legalábbis szerintem jobban kézhez áll. A lassúságát egyáltalán nem írnám az oo számlájára, szerintem valószínűleg amiatt volt lassú, mert mind a 7 örököltetéskor egyesével bővíthették a dom fát saját komponensekkel, ami meg baromi lassú... Ha stringként összefűzték volna a generált kódot, és innerHTML-t használtak volna egyetlen egyszer a kiírásra, akkor valószínűleg sokkal gyorsabb lett volna. Már nem tudjuk meg... Elvileg minden verzió váltásnál gyorsult, meg használhatóbb lett az extjs, de én személy szerint nem bízom benne.

Sokkal jobban szeretek sok kicsi projektet együtt használni, pl underscore, jquery, backbone, bacbone-ui, stb... Mindegyik valamilyen kisebb probléma megoldására specializálódott, nem egy gigantikus valami, mint az extjs... Így nagyobb eséllyel kapok minőségi kódot, csak több idő a könyvtárak összeválogatása, meg valamit nekem kell megírni, ha nem vagyok elégedett egyik kész rendszerrel sem. Most éppen azon dolgozom, hogy rest service-ből érkező adatok alapján automatikusan generáljon a kliensem admin oldalakat, és ne nekem kelljen kézzel megcsinálnom őket...
96

procedurális programozásban

BlaZe · 2013. Szep. 29. (V), 19.02
procedurális programozásban is definiálsz interfészeket (vö. function függvény(paraméter1, paraméter2) és objektum.obj_metódus(paraméter1, paraméter2))

Ez nem interface, hanem szignatúra. OOP-ben az interface nem ezt jelenti, egész pontosan OOP-ben több metódus szignatúráját írhatod le interface-szel (meg pl static fieldeket, inner classt). Ebben az a nagy különbség a függvényhez képest, hogy ugyanazt az interface-t többen is implementálhatják, vagyis az adott interface mögött lévő objektumok teljesen máshogy is viselkedhetnek, de a hívó kódot ez egyáltalán nem érdekli. Függvénynél ezt nem tudod megvalósítani. 1 függvény egyféleképp működik, ha más működést akarsz, új függvényt kell írnod.

A programom felhasználói hozzáférnek a kódhoz, és bármikor átírhatják (és át is írják) a private-ot public-ra, ha a szükség úgy hozza.

Ez nem feltétlenül igaz. Javaban pl kiadsz egy jart, abban már a felhasználónak macerás átírni publicra. Legalábbis a szokásos programozási eszközökkel...
97

Ez nem interface, hanem

Joó Ádám · 2013. Szep. 29. (V), 19.14
Ez nem interface, hanem szignatúra. OOP-ben az interface nem ezt jelenti, egész pontosan OOP-ben több metódus szignatúráját írhatod le interface-szel (meg pl static fieldeket, inner classt). Ebben az a nagy különbség a függvényhez képest, hogy ugyanazt az interface-t többen is implementálhatják, vagyis az adott interface mögött lévő objektumok teljesen máshogy is viselkedhetnek, de a hívó kódot ez egyáltalán nem érdekli. Függvénynél ezt nem tudod megvalósítani. 1 függvény egyféleképp működik, ha más működést akarsz, új függvényt kell írnod.


Ez egy technikai kérdés, irreleváns. Az pedig, hogy függvény esetén nem megvalósítható, simán csak nem igaz, legalábbis a civilizáltabb nyelvekre. Még C-ben is használhatsz függvénymutatót, pláne funkcionális nyelvekben.
99

Egyáltalán nem irreleváns,

BlaZe · 2013. Szep. 29. (V), 19.58
Egyáltalán nem irreleváns, mert a hívó szemszögéből az egyik egy static contract, a másik nem, bármikor megváltozhat a mögöttes működés. Amire készülnie nem kell, de egész más kódszervezési lehetőségeket biztosít a gyakorlatban, és pont erről beszélünk.

A függvénymutatót meg hagyjuk, de tényleg :) Assemblyben is tudsz bárhova jumpolni, mégse vetjük össze egy objektumon végzett metódushívással. Ezt már korábban is felhoztad, és akkor is egyetértettünk benne, hogy azért igen jelentős a különbség a két megoldás között :) Mégha a gyakorlatban ugyanarra is fordul le.
100

Egy függvénymutató valóban

Joó Ádám · 2013. Szep. 29. (V), 20.04
Egy függvénymutató valóban kevesebb garanciát nyújt, mert csak a szignatúrát kódolja, de semmi akadálya annak, hogy egy nyelv függvényinterfészeket is lehetővé tegyen.
101

A szignatúrát se kódolja.

tgr · 2013. Szep. 29. (V), 20.13
A szignatúrát se kódolja. Illetve ami nagyobb baj, hogy lehetetlen statikus elemzéssel kapcsolatba hozni a függvénymutatót a függvénnyel.
105

A szignatúrát se

Joó Ádám · 2013. Szep. 29. (V), 21.01
A szignatúrát se kódolja.


Dehogynem. A függvénymutató típusának része a visszatérési érték típusa és az argumentumok száma és típusa.
116

Vagyis nem kódolja, hanem

tgr · 2013. Szep. 29. (V), 23.10
Vagyis nem kódolja, hanem neked kell megadnod. Megadhatsz más szignatúrát is, mint a tényleges, és akkor ki tudja, mi történik.
117

Ezt nem értem. Ha más

Joó Ádám · 2013. Szep. 29. (V), 23.11
Ezt nem értem. Ha más szignatúrával adok át mutatót, az nem fordul le.
138

Pedig de, és ezzel vissza is

tgr · 2013. Szep. 30. (H), 09.10
Pedig de, és ezzel vissza is élnek viszonylag komoly projektekben is. Pl. itt találsz példákat Gnome-ból, vagy az OpenSSL projektnek is voltak egy időben ebből problémái.
143

Ez nem érv, ha voidot

Joó Ádám · 2013. Szep. 30. (H), 14.18
Ez nem érv, ha voidot használsz, akkor magadra vess, körülbelül olyan, mintha privát adattagokba indexelnél bele karaktermutatóval. (És egy objektummal is minden további nélkül megtehetem, hogy egészen mássá kasztolom, aztán leesik a repülő, ez nem a függvénymutatók sajátossága)
122

Te magad is

Pepita · 2013. Szep. 30. (H), 01.07
A programom felhasználói hozzáférnek a kódhoz, és bármikor átírhatják (és át is írják) a private-ot public-ra, ha a szükség úgy hozza.
Te magad is egy felhasználó vagy. Amit innen kifelejtesz (és nem írtál át publicra semmit még): minden függvényednek, változódnak van egy szülőosztálya, annak pedig egy vagy több példánya. Így nem akkora hibát ejtesz, ha rossz értéket adsz a $valami->ertek-nek, mert ez csak a pl. MyClass osztály, $valami példányában okoz(hat) gondot, de nem borul az egész kódod, mint ha $ertek (globális) változót használsz.
Ugyanez igaz a függvényeidre, ha globálisak, akkor feleslegesen és veszélyesen onnan is elérhetőek, ahonnan nem kéne. Igen, magad elől jó elrejteni, ott, ahol szükségtelen / káros a használata.
És mint fentebb írtam: egy-egy feladatra, összetett adatra írsz egy osztályt, azon belül tetszőleges számú metódust és tulajdonságot: ezt egy egységként tudod kezelni, míg procedurális esetben az össze fv-ed kvázi egy osztály részei.
Nekem pl. adatbáziskezelésben egyik kedvent fv-nevem a get_item($id), procedurális programozásban ezt hogy oldod meg, hogy pl. fórumtémát is kiválaszthass ugyanígy, és blogot is? Nem használhatod u.azt a nevet, pedig leginkább - a tartalomkezelésnél, mint alapvető feladatnál maradva - arra van szükséged átláthatóság és kényelmi szempontból, hogy egy-egy osztályod definiáljon egy-egy tartalomtípust, és ezeknek vannak "közös" fv-eik, mivel mind tartalomtípusok. De amiért más-más tartalomtípusok, ezen fv-ek is kicsit másként működnek.

De nem sokkal átláthatóbb, hogy $forum->get_item(5) és $comments->get_item(85), mint get_forum_item(5), stb.?
És így egy tartalomtípus egy osztályban definiálva lehetővé teszi, hogy amikor pl. hozzászólást szerkesztesz, véletlenül se bántsd (elgépelés miatt) a fórumtémát.
Arról nem is beszélve, hogy pl. a fórumtémádnak van két fő jellemzője (a kiegészítőkön túl): cím és tartalom, egy következő projektedben ez tök jó, de kell még egy felh. név is -> nem írod az elejéről újra, hanem örökítesz egy (fantázia nélkül) Forum2 class-t a korábbi Forum-ból, kiegészíted a megfelelő tulajdonsággal, és a kezelőfv-eit át / felülírod, szükség szerint. Sokkal kevesebb munka, mint újat a 0-ról írni (ezt írták mások is: refaktorálni sokkal könnyebb - persze ha jól használod ki az OO lehetőségeit).

Hogy egy kicsit csaljalak MVC irányba, a fenti $forum->get_item(5) így szép (egy kontroller fv-ében "vagyunk", ami megkapta a HTTP kérést):
$this->load->model(forum); // Van okos loaderünk minden kontrollerhez, 
// mert azok ősosztályában megírtuk, ezért a
$this->forum->get_item(5) // máris használható, mert a loader "beinclude-olta", ha még nem volt, 
// és példányosította nekünk csak ebben a kontrollerben. 
// Ha már volt ilyen load, akkor azt a példányt adja vissza
Így talán jobban látható, hogy kódszervezésben ez mekkora hatalmas előny (és máris volt öröklődés, kényelem, minden).

A függvények is jól definiáltak.
De kb. nincs interfészük. Azazhogy fordítva: mindenhova van interfészük, oda is, ahova nem kéne. (L. fentebb: "azonos" fv-nevek).
98

mitől lesz hordozhatóbb egy

BlaZe · 2013. Szep. 29. (V), 19.37
mitől lesz hordozhatóbb egy OOP kód, mint egy procedurális?

Pl a több szintű absztrakciótól. Tudsz saját interface implementációval módosítani egy külső api viselkedésén, magának az apinak a változtatása nélkül. Amit procedurális kódban nem tudsz megtenni.

milyen előnyökkel jár az adatok elrejtése?

Hogy kívülről nem tudod egy objektum állapotát módosítani, csak a készítője által kiajánlott metódusain keresztül.

ki elől és miért akarnék én bármit is elrejteni?

Mindenki elől, aki nem a fejlesztője az adott osztálynak. Tehát mindenki elől, beleértve magadat is :)

mitől lesz könnyebb refaktorálni az OOP kódot?
miért érint jóval kisebb kódmennyiséget a refaktorálás OOP kódnál?

Ezt MadBence tökjól összeszedte, úgyhogy én nem írom le újból.

mitől lesz az OOP kód áttekinthetőbb?

A több absztrakciótól. A jó OOP kód szinte mondatszerűen, sallangmentesen olvasható. Ez természetesen részben igaz lehet a procedurális kódra is, a különbség az, hogy az OOP ezt nyelvi elemekkel támogatja, procedurálisban pedig teljesen a programozóra van bízva. Ennek eredménye szokott lenni a hosszú spagettikód a kismillió függvényhívással. A szépen szervezett OOP kód nem ilyen. De természetesen láttam már hasonlót OOP nyelven megvalósítva :) Csak úgy érdekességképp: év elején volt egy interjúm, ahol az alábbi kérdést kaptam az interjúztatómtól: "Milyen hosszú egy metódus?" El lehet gondolkodni az okán :) A válasz természetesen az, hogy rövid.

Úgy lehetne viszonylag könnyen ezekre a kérdésekre választ kapni, ha definiálnánk egy feladatot, lefejlesztenénk OOP és procedurális megközelítéssel, és összehasonlítanánk a két megoldást.

Ezt úgy írod, mintha bárkiben is felmerülne ez kérdésként rajtad kívül :)
102

Pl a több szintű

Hidvégi Gábor · 2013. Szep. 29. (V), 20.19
Pl a több szintű absztrakciótól.

Ajánlom figyelmedbe a szivárgó absztrakciók törvényét.

Tudsz saját interface implementációval módosítani egy külső api viselkedésén, magának az apinak a változtatása nélkül. Amit procedurális kódban nem tudsz megtenni.
Szerintem meg lehet tenni, mert nem akadályoz meg benne senki.

»ki elől és miért akarnék én bármit is elrejteni?«
Mindenki elől, aki nem a fejlesztője az adott osztálynak. Tehát mindenki elől, beleértve magadat is :)
Bocs, de ezt nem veszi be a gyomrom. Ha úgy változik a projekt, hogy mégis láthatóvá kell tenni az adott változót vagy metódust, akkor mit csinálok? A főnökömnek bizonygatom, hogy ez lehetetlen, és közben a jobb kezemmel a bal kezemet verem, mert át akarja írni a private-ot public-ra?

Én magam elől nem szeretnék elrejteni semmit. De ez akkor maradjon az én bajom.

az OOP ezt nyelvi elemekkel támogatja
(azt, hogy a kód szinte mondatszerűen, sallangmentesen olvasható) - mik ezek a nyelvi elemek?

Milyen hosszú egy metódus?
Amilyen hosszúnak lennie kell.

Ezt úgy írod, mintha bárkiben is felmerülne ez kérdésként rajtad kívül :)
Indiába nem csak Afrika megkerülésével lehet eljutni.
106

Ajánlom figyelmedbe a

Joó Ádám · 2013. Szep. 29. (V), 21.05
Ajánlom figyelmedbe a szivárgó absztrakciók törvényét


És ebből azt a következtetést vontad le, hogy az absztrakció rossz dolog? A törvény arról szól, hogy az absztrakció lényege nem az, hogy ne kelljen ismerd a megvalósítást, csak hogy az esetek többségében ne kelljen vele foglalkozz.

Bocs, de ezt nem veszi be a gyomrom. Ha úgy változik a projekt, hogy mégis láthatóvá kell tenni az adott változót vagy metódust, akkor mit csinálok?


Akkor kivezeted az interfészre.
109

Igen, minél több az

Hidvégi Gábor · 2013. Szep. 29. (V), 21.51
Igen, minél több az absztrakció, annál távolabb kerülünk a valóságtól.

Az absztrakt szó jelentése: Elvont, elméleti, gondolati. A valóság összefüggéseivel nem törődő, a szokásos formákat megbontó.
Azért ez elég súlyos.

Akkor kivezeted az interfészre.
Akkor ezt az egész adatrejtést úgy lehetne modellezni, hogy van egy gépezetem, amin bizonyos gombok mellé oda van írva, hogy "Ezt nem szabad megnyomni, különben..." Különben mi lesz? Semmi, "kivezetem az interfészre".
110

Akkor ezt az egész

Joó Ádám · 2013. Szep. 29. (V), 21.52
Akkor ezt az egész adatrejtést úgy lehetne modellezni, hogy van egy gépezetem, amin bizonyos gombok mellé oda van írva, hogy "Ezt nem szabad megnyomni, különben..." Különben mi lesz? Semmi, "kivezetem az interfészre".


Nagyon jó példa. Azért vannak gombok a gépen, hogy ne kábelek összeérintésével kezeld, mert egyrészt kényelmetlen derékig bebújni a dobozba, másrészt nincs elég kezed mindet tartani, harmadrészt bármikor kihagyhatsz egy lépést, és akkor leég az egész.

Ha kell egy új funkció, akkor tegyél ki egy gombot. Ha időközben rájössz, hogy máshogy akarod megvalósítani, a gomb marad, csak átdrótozod.
124

+10

Pepita · 2013. Szep. 30. (H), 01.18
Gábor, ez már remélem meggyőz!
111

Igen, minél több az

Joó Ádám · 2013. Szep. 29. (V), 21.55
Igen, minél több az absztrakció, annál távolabb kerülünk a valóságtól.


Az információ maga absztrakt, a valóságban nem létezik ilyesmi. Innentől kezdve miről beszélünk?
120

Én már elvesztettem a fonalat

inf3rno · 2013. Szep. 30. (H), 01.01
Én már elvesztettem a fonalat :D Szerintem ti sem tudjátok :D
112

Szerintem meg lehet tenni,

BlaZe · 2013. Szep. 29. (V), 22.00
Szerintem meg lehet tenni, mert nem akadályoz meg benne senki.
int x = add(a,b);
Ezt hogy írod át, hogy ne összeadja a 2 számot, hanem összeszorozza? Kódváltoztatás nélkül természetesen.

Bocs, de ezt nem veszi be a gyomrom. Ha úgy változik a projekt, hogy mégis láthatóvá kell tenni az adott változót vagy metódust, akkor mit csinálok? A főnökömnek bizonygatom, hogy ez lehetetlen, és közben a jobb kezemmel a bal kezemet verem, mert át akarja írni a private-ot public-ra?

Nem, ilyet sosem akarsz csinálni. Pont ez a lényege. A főnököd se fog ilyet kérni, mert vagy technikai ember és tudja, hogy ilyet nem csinálunk, vagy nem technikai ember, és akkor erről nem is dönt.

Amilyen hosszúnak lennie kell.

Ezzel a válasszal tuti hazaküldenének :)

Indiába nem csak Afrika megkerülésével lehet eljutni.

Góg és Demagóg fia vagyok én... :) Az a baj, hogy te egy széles körben elfogadott, és egy komplett szakma által gyakorlati tapasztalattal alátámasztott tényt próbálsz meg állandóan vitatni azzal, hogy lehet szarul is csinálni. Persze. De ez már a kockázatkezelés témaköre inkább, ez pedig a project management/lead feladata, nem a technológiáé. Erre vannak a reviewk pl.
113

int add(int a, int b) { 

Hidvégi Gábor · 2013. Szep. 29. (V), 22.27
int add(int a, int b) {
  return a * b;
}
(A feladatmeghatározásod nem volt pontos.)

A főnököd se fog ilyet kérni, mert vagy technikai ember és tudja, hogy ilyet nem csinálunk, vagy nem technikai ember, és akkor erről nem is dönt.
Teljesen mindegy, hogy technikai vagy sem, ha a feladatot csak úgy lehet megoldani, akkor láthatóvá kell tenni az adott tagot és kész.

Ezzel a válasszal tuti hazaküldenének :)
Ha van egy feladat, amit végre kell hajtani, akkor ha azt ötszáz sorból lehet megoldani, akkor ötszáz soros lesz a metódus. Nem egy elméletnek szeretnék megfelelni, amikor programozok, hanem az igény szerint.

Az a baj, hogy te egy széles körben elfogadott, és egy komplett szakma által gyakorlati tapasztalattal alátámasztott tényt próbálsz meg állandóan vitatni azzal, hogy lehet szarul is csinálni.
Pontosítok: ismereteim és tapasztalataim alapján van hatékonyabb módszer az OOP-nél szoftverkészítésre (és Ádám kommentjei miatt finomítok: az OOP szintaktikát értem ez alatt, azaz az adatrejtést, az öröklődést és a polimorfizmust), mert nincs rá bizonyíték, hogy az OOP-vel készített kód bármiben is jobb lenne a procedurálisnál, de cserébe olyan látásmódot kényszerít a használójára, amivel túlzottan leegyszerűsíti a világot, valamint túlbonyolítja a szoftvert. Lehet, hogy sokan használják, de szükségesnek tartom, hogy az emberek megismerjenek alternatívákat, mert fentebb MadBence is linkelte, hogy ez nem épp a szent grál.
118

De, a feladatmeghatározásom

BlaZe · 2013. Szep. 29. (V), 23.53
De, a feladatmeghatározásom tök pontos volt. Arra akartam rávilágítani, hogy az add() meghívása mindig össze fogja adni a két számot és csak akkor tudod szorzássá alakítani, ha a hívó helyén megváltoztatod a függvényhívást mul()-ra. De akkor a hívó már csak szorozni fog tudni. OOP-nél ezzel szemben egy interface-en függ a kódod, és hívó oldali változtatás nélkül tudsz bármilyen műveletet végezni attól függően, hogy milyen objektumot kap paraméterként. Itt van a példa. Nyilván senki nem csinál ilyet, még mielőtt jönnél, hogy hülyeség ennyire overengineerelni egy tök egyszerű aritmetikai műveletet, ez csak egy példa ;) Gondolj arra, hogy ez egy adatfelolvasás, és XML, CSV, SQL a források.

Ha van egy feladat, amit végre kell hajtani, akkor ha azt ötszáz sorból lehet megoldani, akkor ötszáz soros lesz a metódus. Nem egy elméletnek szeretnék megfelelni, amikor programozok, hanem az igény szerint.

Na ilyen az a kód, amivel én nem akarok találkozni munkám során :) Ha egy recordset felolvasását, feldolgozását, és kiíratását végzi egy metódus (amit ugye nem csinál, de tegyük fel, hogy igen), akkor abban a metódusban 3 metódushívást akarok látni: fetch, process, write. Hogy ezek belül mit csinálnak, nem érdekel, mert nem azon az absztrakciós szinten vagyok, ahol ezzel akarok foglalkozni. Ha 500 sor, ciklusok, változókkal mókolások stb... Az áttekinthetetlen, és olvashatatlan. Ami nem fér ki kb egy képernyőre, az már egy jelzés, hogy ki kéne emelni dolgokat külön metódusba. Ez persze nem egy beégetett szabály, de általában jól jelzi, hogy túl sokminden került a metódusba.

És hogy nem elméletnek programozol... Az elméletedről szól az egész vita szemben a többiek gyakorlati alkalmazási tapasztalatával :)

Lehet, hogy sokan használják, de szükségesnek tartom, hogy az emberek megismerjenek alternatívákat, mert fentebb MadBence is linkelte, hogy ez nem épp a szent grál.

Ismerjük szerintem mind a procedurális programozást, azzal kezdtünk. Majd azt választottuk, hogy OOP-ben programozunk, mert a gyakorlati tapasztalatunk szerint ez kifizetődőbb. Nekem továbbra is az az érzésem, hogy nem érted miről szól az egész, és mumusnak tekinted. Ami a te bajod, csak ha sok helyen leírod, hogy az OOP szar és túlbonyolítás, ráadásul mindezt elég nagy hangerővel és meggyőződéssel, akkor könnyen lehet, hogy lesznek, akik elhiszik. Főleg, mivel elsőre sokan nehézkesnek találják. És mondjuk egy Pascalról Javara váltás (ami egy tipikus lépés az oktatásban) valóban nem zökkenőmentes. Bevallom, elsőre én is baromságnak és túlbonyolításnak éreztem az egészet. Főleg assembly után tűnt istenkáromlásnak. De miután tudtam hová tenni, és lett belőle valódi gyakorlati tapasztalatom, már egész mást gondolok róla. Azt ajánlom, hogy olvass el pár könyvet a témában. Valami jó OOP alapozó, aztán Design patterns, végül Clean code. Ha a végére sem változik meg a véleményed, akkor ez van :)
125

Pontosabban? :)

Pepita · 2013. Szep. 30. (H), 01.41
Ami nem fér ki kb egy képernyőre, az már egy jelzés
Mekkora képernyő, milyen betűmérettel? (Csak rossz vicc, nagyobb részben egyetértek.)

Ami azért kicsit megfontolandó, és ha már említetted ezeket a programnyelveket:
- Tegyük fel, hogy Assemblyben, Pascalban és Javaban egyformán jó programozó vagy.
- Akkor ugyanaz a (pl. számítási) feladat futásideje Assemblyben lesz a legkisebb, Javaban a legnagyobb. Ugyanez memóriafelhasználásban is.
- Ugyanakkor a fejlesztési időd pont fordítottan arányos, de lássuk be:
- Struktúrált program (a lefordított végeredmény) általában kisebb és gyorsabb, mint OOP.
- Viszont nagy kérdés, hogy megéri-e az időráfordítást, és a kb. változtathatatlanságot? (Ez mondjuk túlzás, mert Assemblyben is lehet szép kódot írni, de akkor is nehezebb átírni.)

Ha Pascal alatt ObjectPascalt (vagy azt is) tanítanának, nem lenne akkora szakadék. Nálunk elkövették azt a hibát (2004-től), hogy Assembly, Java, Delphi a sorrend. Pedig (főként "sima" Pascal után) az ObjectPascalt könnyen érthetőnek találom, inkább, mint Java-t.
Persze Assembly a "kapu", voltak páran, akik 3. éve járták...
De a Java oktatómmal (tök jó fej volt, kb. egyidős) Java-gyakorlat keretében számtalanszor versenyeztünk: ki csinálja meg hamarabb az adott játékfeladatot, ő Java-n, vagy én Delphiben... :) Így nem volt annyira idegen és amellett érdekes is, mindenki számára (én meg csak kb. otthon nyűglődtem a Java-val :( ).
127

Viszont nagy kérdés, hogy

inf3rno · 2013. Szep. 30. (H), 02.09
Viszont nagy kérdés, hogy megéri-e az időráfordítást, és a kb. változtathatatlanságot?


Ennek nem sok köze van az oo vs struktúrált vitához. A java azért lassabb, mert virtuális gépen fut, egyébként az oo kódra azt mondják, hogy nagyságrendileg ugyanolyan gyors, mint a nem oo. Ha ettől eltekintünk, akkor a programozó néhány órás munkája kerül kb annyiba, mint a plusz vas egy évig, szóval egyáltalán nem éri meg emiatt assembly-t választani (szerintem) ... Az erőforrás igényesség inkább tömegtermékeknél szempont az olcsóság, kisebb méret, fogyasztás stb.. miatt, de pl mobiloknál is vannak már annyira erősek és takarékosak az arm processzorok, hogy ott is jobban megéri java-ban programozni, illetve egy másik témában is előkerült, hogy vannak már a mobilokhoz hasonló méretben single board computer-ek, amiket szintén lehet használni célfeladatra. Ezzel kapcsolatban most pont is van egy csomó ötletem, építeni fogok 4 rotoros robot helikoptert, quadro micsodát, meg öntöző rendszert, meg még ki tudja mit :D
136

De, a feladatmeghatározásom

Hidvégi Gábor · 2013. Szep. 30. (H), 08.37
De, a feladatmeghatározásom tök pontos volt.
Akkor én értettem félre, mert azt hittem, hogy az add() már az interface része. Így egy sima if+else vagy egy switch megoldja a problémát.

Ha egy recordset felolvasását, feldolgozását, és kiíratását végzi egy metódus (amit ugye nem csinál, de tegyük fel, hogy igen), akkor abban a metódusban 3 metódushívást akarok látni
Szerintem egyezzünk meg abban, hogy ez szokás kérdése. Én azokat a dolgokat szoktam kitenni függvénybe, amit egynél többször végzek el. Nem zavar, ha 500 soros a függvény, mert ahogy végiggörgetek rajta, átláthatom az egészet, míg ha darabokra van robbantva, ide-oda ugrálhatok a kódban.

Az elméletedről szól az egész vita szemben a többiek gyakorlati alkalmazási tapasztalatával :)
Ne haragudj, de egy vitában nem túl erős érv a tekintélyre utalni: a középkorban embereket égettek meg azért, mert boszorkánynak tartotta őket a nép és/vagy a vallás. Az indiai hasonlattal is többek között erre próbáltam célozni.

Nekem továbbra is az az érzésem, hogy nem érted miről szól az egész, és mumusnak tekinted.
Nézd, az embernek sokszor nehéz elfogadnia a saját korlátait. Akárhogy is, de elvégeztem egy Műszaki Egyetemet, ahol azért messze nem csak a biflázásról szólt az egész, tehát végtelenül hülye mégsem lehetek (remélem legalábbis). És mégis, itt van ez az OOP, amivel először körülbelül húsz éve találkoztam, és már az első pillanattól bennem volt, hogy itt valami nem kóser. Azóta nem egyszer futottam neki, elméletben és gyakorlatban is, és ez az érzésem csak erősödött. Pedig az alapjai egyszerűnek tűnnek.
156

Szerintem egyezzünk meg

BlaZe · 2013. Szep. 30. (H), 22.42
Szerintem egyezzünk meg abban, hogy ez szokás kérdése. Én azokat a dolgokat szoktam kitenni függvénybe, amit egynél többször végzek el. Nem zavar, ha 500 soros a függvény, mert ahogy végiggörgetek rajta, átláthatom az egészet, míg ha darabokra van robbantva, ide-oda ugrálhatok a kódban.

Nem akarlak meggyőzni, és ez a vita aztán tényleg messzire vezetne. Adtam könyvcímet a témában, ha érdekel, majd utánaolvasol.

Ne haragudj, de egy vitában nem túl erős érv a tekintélyre utalni

Egyáltalán nem erre gondoltam. Csak azt írod, hogy nem akarsz elméletnek kódolni, és közben pont hogy megkötöd magad ezzel az elmélettel, hogy kizárod az OOP-t a palettáról, noha egy baromi hasznos eszköz.

Nézd, az embernek sokszor nehéz elfogadnia a saját korlátait. Akárhogy is, de elvégeztem egy Műszaki Egyetemet, ahol azért messze nem csak a biflázásról szólt az egész, tehát végtelenül hülye mégsem lehetek (remélem legalábbis).

Távol álljon tőlem, hogy ilyet gondoljak rólad. Viszont annyira sikerült megismerjelek, amikor együtt dolgoztunk, hogy szeretsz a nagy tömeggel ellentétes irányba haladni. Attól függetlenül, hogy a tömeg jó, vagy rossz irányba halad. A kritikus szemlélet valóban hasznos, de azon azért érdemes elgondolkodni, hogy a szakmánk eléggé gyakorlat vezérelt, és többnyire ebből alakulnak ki a mögöttes elméletek, nem pedig fordítva.
160

szeretsz a nagy tömeggel

Hidvégi Gábor · 2013. Okt. 1. (K), 14.03
szeretsz a nagy tömeggel ellentétes irányba haladni. Attól függetlenül, hogy a tömeg jó, vagy rossz irányba halad.
Ez nem teljesen így van. Vannak igényeim, és megnézem, hogy az adott eszköz ennek megfelel vagy sem. Ha nem, akkor nem fogom csak azért is használni, mert százmillió embernek megfelel.

A kritikus szemlélet valóban hasznos, de azon azért érdemes elgondolkodni, hogy a szakmánk eléggé gyakorlat vezérelt, és többnyire ebből alakulnak ki a mögöttes elméletek, nem pedig fordítva
A szakmánk szerintem nem gyakorlatvezérelt, hanem divatvezérelt, és többnyire nélkülözi a józan megfontolásokat. Példa: a CSS statikus, a HTML statikus, a HTML-ben szinte egyáltalán nincs lehetőség metaadatok megadására, a megadható metaadatok száma elhanyagolható, a harmadik féltől származó scriptek futtatásának lehetősége miatt az internetes támadások 84%-a XSS (2007-es adat, a Wikipédiából).
161

Nem értem

Pepita · 2013. Okt. 2. (Sze), 03.18
Gábor, én komolyan nem értem, hogy haragudhatsz ennyire egy paradigmára. Ez is egy eszköz, van ahol jó használni, van ahol nem. Te viszont - úgy látom - azt gondolod, hogy sehova sem jó. Ebben nincs igazad, mind szakmailag, mind üzletileg többször van létjogosultsága, mint mikor nincs (ebben viszont egyetértek, hogy nem mindig ez a jó megoldás).
A szakmánk szerintem nem gyakorlatvezérelt, hanem divatvezérelt, és többnyire nélkülözi a józan megfontolásokat.
Ez kicsit túlzás, de van benne igazság is. Ezt gondold meg: én divatból (szerintem) soha nem csinálok semmit, mégis MVC-kedvelő (OOP) vagyok.
A felhozott példáid (dinamikus HTML-CSS) szerintem rosszak. Azok jók statikusnak, ott a DOM, amin variálhatsz.
a harmadik féltől származó scriptek futtatásának lehetősége miatt az internetes támadások 84%-a XSS
Ezzel maximálisan egyetértek. Irtani kéne az ilyen cuccokat a honlapokról, nem szaporítani. De sajnos ennek is van üzleti oldala is: gyorsabb egy ingyom-bingyom API-t odatenni (tudod: a barátod:)), mint írni sajátot. Ezzel együtt én sem teszem - éhen is halok lassan. :)
(Lehet lesz egy ehhez kapcsolódó kérdésem, de még érik és más téma.)
162

Igazad van, nem tetszik az

Hidvégi Gábor · 2013. Okt. 2. (Sze), 07.46
Igazad van, nem tetszik az OOP, különösen az öröklődés és a polimorfizmus, mert rámerőltet egy gondolkodási módot, amivel csak egyféleképp láthatom a dolgokat.

A felhozott példáid (dinamikus HTML-CSS) szerintem rosszak. Azok jók statikusnak, ott a DOM, amin variálhatsz.
A DOM-on csak scripttel variálhatok, amit meg még arra használnak, hogy XSS támadásokat hajtsanak vele végre. Emellett elvesztem a tartalom részeinek kliensoldali gyorstárazásának lehetőségét.
163

A DOM-on csak scripttel

inf3rno · 2013. Okt. 2. (Sze), 08.10
A DOM-on csak scripttel variálhatok, amit meg még arra használnak, hogy XSS támadásokat hajtsanak vele végre. Emellett elvesztem a tartalom részeinek kliensoldali gyorstárazásának lehetőségét.


Hát szűrni kell XSS-re, a gyorstárazást meg meg lehet oldani localStore-al, ha nagyon fontos.
164

Majdnem

Pepita · 2013. Okt. 2. (Sze), 20.48
Köszönöm, hogy igazat adsz, de van egy kis bibi (lehet itt lesz számodra a megoldás):
rámerőltet egy gondolkodási módot, amivel csak egyféleképp láthatom a dolgokat.
Pont olyan gondolkodási módot "erőltet" rád, amivel min. többmillióféleképp láthatod a dolgokat. Persze itt is vannak (jól-rosszul) bevált szokások, de teljesen szabad vagy, főként gondolkodásban. Egyszerű pl.: nem kötelező örökíteni. Sokszor hasznos, de nem mindig, és ha te úgy gondolod, akkor sem örökítesz, ha hasznos lenne - mások szerint. Teljesen a magad ura vagy. Hidd el nekem (ismersz annyira, hogy nem hazudok): a procedurális kódolással sokkal jobban megkötöd a kezed. Én mindkettővel sok jó és rossz kódot gyártottam, több nyelven.
A DOM-on csak scripttel variálhatok, amit meg még arra használnak, hogy XSS támadásokat hajtsanak vele végre
Egyrészt: Inf3rno-nak +1.
Másrészt: légyszíves válogasd meg az általad készített oldalon, hogy csak a saját scriptedet használod. Azt hiszem ebben nagyon is egyetértünk. Ezzel ez a fajta XSS kilőve.
Harmadszor: ha betartasz néhány spórolós aranyszabályt (ami sajnos megintcsak nagyonnem divat manapság), akkor simán megcsinálod backend az egész oldalt, és nem foglalkozol vele, hogy a fejléc pl. mindegyiken ugyanaz (egyébként ha pl háttérkép, akkor tudod, hogy külön cacheli). Ha üres / kikapcsolt cache mellett a teljes oldal kevesebb, mint 3-400 kB, akkor kár is foglalkozni a darabonkénti töltéssel. Emellett persze a HTTP kérések száma is, stb. Máris kidobhatod egyben a js-t is, legfeljebb csili-vili, + kliensoldali ellenőrzés, stb-re.
De ezeket te mind tudod, ezért nem értem ezt a részt.
121

Már hogy ne lenne rá

inf3rno · 2013. Szep. 30. (H), 01.05
Már hogy ne lenne rá bizonyíték. Az oop kód olvashatóbb, mint a struktúrált, könnyebben kereshetőek és cserélhetőek benne a komponensek. A névterek, az osztály és metódusnevek a kód kereshetőségét segítik elő. Struktúráltan ugyanezt csak kilométer hosszú függvény nevekkel lehet elérni, ami meg távol áll a könnyen emészthetőtől. Nyilván ha nem vagy tisztában azzal, hogy mennyire fontos egy-egy kód karbantarthatósága, akkor 500 soros függvényeket írsz, utána meg ha valamit módosítanod kell, akkor végignézed mind az 500 sort mire megtalálod. Ha szétbontod az 500 sorodat 5 osztályra, osztályonként 5-10 metódusra, akkor megnézed az 5 osztály nevet, kiválasztod, hogy melyikben van, amit keresel, utána megnézed az 5 metódus nevet, kiválasztod azt a metódust, amiben az adott dolog van, aztán végignézed a metódus kódját, ami 10 sor, és máris megvan, hogy hol kell belenyúlnod a kódba. Szóval csak ebben a példában 25x gyorsabb a kód kereshetősége, és akkor csak egy 500 soros kis valamiről beszélünk... Struktúráltan is lehet finomszemcsés kódot írni, de mivel abban nincs megtámogatva a dolog, ezért maximum annyit tudsz tenni a kereshetőség érdekében, hogy szétosztod fájlok között a függvényeidet.
126

Na ezért nincs értelme

Joó Ádám · 2013. Szep. 30. (H), 01.58
Na ezért nincs értelme OOP-ről beszélni, mert annyi mindenre húzzák rá az emberek, hogy lassan semmit nem jelent. A névter is lassan ötven éves találmány, a Modula és az Ada procedurális nyelv létére már a kezdetektől rendelkezett modul-/csomagrendszerrel.
145

Én csak a php-re szorítkoztam

inf3rno · 2013. Szep. 30. (H), 18.08
Én csak a php-re szorítkoztam a válaszommal, nyilván ahol van névtér, ott kereshetőség szempontjából ki lehet váltani azzal az osztályokat.
149

Tudtommal már a PHP-ban is

Joó Ádám · 2013. Szep. 30. (H), 18.35
Tudtommal már a PHP-ban is van.
150

Azt hiszem az 5-ös verziótól.

inf3rno · 2013. Szep. 30. (H), 18.37
Azt hiszem az 5-ös verziótól. Az autoload viszont ha jól tudom csak osztályokra működik...
157

5.3-tól. Az autoload-hoz

tgr · 2013. Okt. 1. (K), 00.27
5.3-tól. Az autoload-hoz nincs köze.
158

Van olyan nyelv, ahol az

inf3rno · 2013. Okt. 1. (K), 00.31
Van olyan nyelv, ahol az autoload függvényekre is működik?
159

Lua, például.

tgr · 2013. Okt. 1. (K), 08.45
Lua, például.
103

A központi koncepció az

tgr · 2013. Szep. 29. (V), 20.24
A központi koncepció az OOP-ben szerintem az implementáció és a specifikáció különválasztása. Ha C-ben azt mondod, hogy do_stuff(foo, bar, baz), azzal hozzákötötted a do_stuff() függvényt felhasználó kódot a do_stuff() konkrét implementációjához. Ha PHP-ben azt mondod, hogy $obj->doStuff($foo, $bar, $baz), akkor a specifikációhoz hozzá van kötve a kód (feltéve, hogy $obj osztálya vagy interfésze ismert), de az implementációhoz nem.

Hasonló különbség van a reduce(int** array, int default, int (*funcptr)(int, int)) és a reduce(Iterable iter, Callback cb) között is, csak ott meg az argumentumként várt adatstruktúra implementációjához köti vagy nem köti magát a függvény.
107

Ha C-ben azt mondod, hogy

Joó Ádám · 2013. Szep. 29. (V), 21.12
Ha C-ben azt mondod, hogy do_stuff(foo, bar, baz), azzal hozzákötötted a do_stuff() függvényt felhasználó kódot a do_stuff() konkrét implementációjához.


Magamat ismétlem, de ha mutatón keresztül hívod a függvényt, akkor máris elválasztottad a kettőt.
114

Ha mutatón keresztül hívod a

tgr · 2013. Szep. 29. (V), 22.58
Ha mutatón keresztül hívod a függvényt, akkor nincs kötve se implementációhoz, se specifikációhoz, ami általában nem jó dolog.
115

Igen, ez tényleg egy gyengébb

Joó Ádám · 2013. Szep. 29. (V), 23.05
Igen, ez tényleg egy gyengébb contract, mert csak formai követelménye van, szemantikai nincs, de magára az implementáció leválasztására legalább van lehetőséged. (És lássuk be, egy osztályinterfész esetén is csak a bizalom garantálja, hogy a megvalósító példány a specifikáció szerint viselkedik.)
139

Meg a unit tesztek. De

tgr · 2013. Szep. 30. (H), 09.20
Meg a unit tesztek. De alapvetően nem a bizalom hiánya itt a probléma, hanem hogy össze tudod-e kötni statikusan a függvényhívást a specifikációval (pl. feldobni IDE-ben a függvény dokumentációját, vagy megtalálni az interfész refaktorálásakor) anélkül, hogy egy konkrét implementációhoz is hozzákötöd. Nem OOP nyelvek ezt jellemzően nem tudják megtenni.
146

Unit teszteket is ugyanúgy

inf3rno · 2013. Szep. 30. (H), 18.13
Unit teszteket is ugyanúgy lehet írni szerintem struktúrált kódra, semmi nem gátol meg benne, hogy 1-1 függvényt tesztelj. Amivel már nagyobb a gond, hogyha a függvények egymást hívják, akkor nem tudod kimockolni a meghívott függvényeket. Legalábbis php-ben szerintem erre nincs lehetőség, vagy külön teszt futtatót kellene írni hozzá 1 teszt 1 php kérés alapon, amire meg szerintem nem sokan vállalkoznának... Szóval ha egy oo kód használ dependency injection-t, akkor az sokkal jobban tesztelhető, mint bármelyik struktúráltan írt kód ugyanarra a témára.
151

Ha használ. De ha a

Joó Ádám · 2013. Szep. 30. (H), 18.41
Ha használ. De ha a strukturált kód mutatókat használ, akkor azt is lehet mockolni.
63

Adattípusok

Hidvégi Gábor · 2013. Szep. 16. (H), 10.04
Igazad van, nekem az adattípusokkal (is) lehet bajom. Belegondoltam, és mindig is csak a primitíveket használtam: karakterlánc, szám, valamint ezek kombinációja (többdimenziós) tömbökben.
64

Neked is COBOL-t kellett

H.Z. · 2013. Szep. 16. (H), 11.30
Neked is COBOL-t kellett volna tanulnod első nyelvként! ;)
65

Érdekelne

Pepita · 2013. Szep. 16. (H), 23.09
A COBOL milyen nyelv? Van valami leírás, Hello world róla? Mikor tanultad elsőként?
Sosem hallottam róla, érdekelne, mint indok.
67

A cobol baromi régi nyelv,

inf3rno · 2013. Szep. 17. (K), 00.04
A cobol baromi régi nyelv, nem használják szélesebb körben, ha egyáltalán még használják. Ahogy nézem - wikipedia szerint - y2k probléma emiatt volt, és baromi sokan használták akkor még főleg üzleti alkalmazásoknál. Nem tudom, hogy azóta mi lehet a helyzet.
68

Szerinted miben írták a

Joó Ádám · 2013. Szep. 17. (K), 00.09
Szerinted miben írták a bankod teljes backendjét? :) A világ pénzügyi rendszere máig COBOL-on fut.
69

Tehát a világ pénzügyi

inf3rno · 2013. Szep. 17. (K), 00.11
Tehát a világ pénzügyi rendszerében sok évtizedes kódok vannak? Biztos, hogy jó ez így?
70

„If it ain’t broke, don’t fix

Joó Ádám · 2013. Szep. 17. (K), 00.15
„If it ain’t broke, don’t fix it” :)
71

Vágom, de biztonsági

inf3rno · 2013. Szep. 17. (K), 00.17
Vágom, de biztonsági szempontból nem kell frissíteni? Úgy értem, hogy nap, mint nap jönnek ki újabb támadási technikák, gondolom ez a banki rendszerekre is érvényes...
72

Nem véletlenül írtam

Joó Ádám · 2013. Szep. 17. (K), 00.20
Nem véletlenül írtam backendet, a webbank felület nyilván nem COBOL. De természetesen a frissítést végzik a COBOL programozók :)
73

Okés! :-)

inf3rno · 2013. Szep. 17. (K), 00.21
Okés! :-)
74

Kiokosított Assembly

Pepita · 2013. Szep. 17. (K), 00.32
Így első ránézésre jól "megfullosított" assembly. Jó prociközeli lehet, jobban megnézem. :)
77

Akkor te valami mást láttál.

H.Z. · 2013. Szep. 17. (K), 08.59
Akkor te valami mást láttál. Assembly-hez annyi köze van, hogy a legtöbb fordítóprogramja assembly-re, onnan gépikódra fordított és az assembly kódba ha nagyon merész voltál, akár bele is nyúlhattál.

A COBOL (ANSI) egy hihetetlenül szószátyár, adatkezelésre kitalált nyelv (COmmon Businness Oriented Language).

Hello World

Adatbázis kezelést meg ahány nyelvjárás annyiféleképp oldották meg benne, mert szabványosan csak az index-szekvenciális fájlok kezelésére volt felkészítve.

Viszont, ami a fenti példán nem igazán látszik, az adatstruktúrák leírása elég jól olvasható volt benne.
79

Hát...

Pepita · 2013. Szep. 17. (K), 09.37
Akkor te valami mást láttál.
Wikipediat. Alaputasítások, szerkezet, eléggé hasonlít. Ezért is fordít úgy, ahogy írod. Én "merész" vagyok assemblyben, valószínűleg ezért is tetszett első felépítésre.

Köszi a Hello World-öt, azon látszik, hogy szeret proc-okba csoportosítani (assembly), ami előny is és hátrány is (stack) lehet.

a fenti példán nem igazán látszik, az adatstruktúrák leírása elég jól olvasható volt benne
Ettől függetlenül elhiszem, pont ezzel adhatott jóval többet assembly-nél. Mivel egyszerű, prociközeli nyelv, örülj a fájlkezelésnek, ne akarj mindjárt "pdo drivert" hozzá...

Nekem valószínűleg tetszett volna, ha dolgom akad vele. Persze könyv stb. után, ezt csak úgy első ránézésekre mondom.
81

Épp ez az, hogy egyáltalán

H.Z. · 2013. Szep. 17. (K), 14.35
Épp ez az, hogy egyáltalán nem processzor közeli nyelv. Sőt... Kb. annyira, mint bármely más, 3. generációs nyelv, ami nem köztes kódra fordul, hanem gépire.
(FORTRAN, PL/I, Algol, Pascal - ezek nem igazán gépközeli nyelvek. A C az egyetlen kivétel)
82

Hát akkor nem nyert

Pepita · 2013. Szep. 19. (Cs), 01.58
Nem mintha épp most akarnék (nekem) új nyelvbe tanulni. De elsőre úgy tűnt.
76

Az már rég volt. :( Már

H.Z. · 2013. Szep. 17. (K), 08.54
Az már rég volt. :(
Már amikor én dolgoztam rajta, akkor sem COBOL-t használtunk, pedig annak már több, mint húsz éve.
80

Mástól egy-két éve hallottam,

Joó Ádám · 2013. Szep. 17. (K), 14.10
Mástól egy-két éve hallottam, hogy ugyanúgy COBOL az egész rendszerük. Nálatok mivel váltották le?
86

Leginkább Java, vagy az

BlaZe · 2013. Szep. 29. (V), 08.43
Leginkább Java, vagy az igazán sebességkritikus helyeken Java C-vel kombinálva fut már a legtöbb helyen. Frontenden nyilván JEE, a "realtime" backendeken (pl FX és egyéb pénzpiaci rendszerek) leginkább low latency Java. Legalábbis amikről én tudok, azok így néznek ki.
93

És miért használsz különböző

Joó Ádám · 2013. Szep. 29. (V), 15.55
És miért használsz különböző primitíveket? Tárolhatnál mindent sztringekben. Azért, mert nyilvánvalóak az előnyei mind fejlesztési időben, mind memória- és számítási igényben, hogy a feladathoz illeszkedő típust használsz. A PHP asszociatív tömbjeit pedig azért használod, mert saját adattípusokat akarsz, csak ehhez a lehető legkevésbé hatékony eszközt használod mind fejlesztési időben, mind memória- és számítási igényben.

Belegondoltál már, hogy mennyit vesztesz teljesítményben azzal, hogy tömböket (olcsó indexelés, olcsó bejárás), listákat (olcsó módosítás), hash táblákat (optimális egyensúly méret és indexelési sebesség közt) és adatstruktúrákat (olcsó mezőelérés) ugyanazzal a generikus megvalósítással reprezentálsz? Figyelem, akasztják a hóhért: és milyen hatása van ennek a környezetre? :)

Azt, hogy az asszociatív tömbök használatát sem a fordító (statikus típusrendszerben), sem a futtatókörnyezet (dinamikus típusrendszerben) nem tudja ellenőrizni, már nem is említem.
83

Erős statikus típusosság

Hidvégi Gábor · 2013. Szep. 28. (Szo), 19.18
Már jóideje filozofálok ezen, de nem tudom megérteni, mire is jó ez pontosan.

Szedjük darabokra, célszerű hátulról:
1, típusosság: tudom egy értékről, hogy karakterlánc, szám stb.
2, statikus: nem változó, fix
3, erős típusosság: pontosan tudom, hogy milyen típusú az érték, azaz hány bájtos egész szám/lebegőpontos

Egy szoftver sosem statikus, akár napról napra változhatnak a megrendelő igényei, mert ő sem tudja pontosan elsőre (másodszorra) lemodellezni azt, amire szüksége van. Ha erősen statikus valami, akkor emiatt mindenképp hátrányba kerülök.

Ha mindezt beteszem egy objektumorientált környezetbe, ahol többszörös öröklődés is van, és mondjuk az alap osztályt vagy köztes arcot kell módosítani, ráadásul az OOP jellegéből adódóan a programkódba hardkódolva van az adattípusok "viselkedése", azzal rengeteg plusz munkát csinálok magamnak.

Akárhonnan nézem, ezt egy nagyon merev szerkezetnek látom, ami idővel, a szoftver szükségszerű hízásával egyre nagyobb problémákat fog okozni.
84

Statikus típusosság: ha van

MadBence · 2013. Szep. 28. (Szo), 19.45
Statikus típusosság: ha van egy változód, akkor ott fordításkor tudod, hogy milyen típus fog tartózkodni.
Erős típusosság: nincs varázslás a típusok között (ez nem feltétlenül azt jelenti, hogy nincs implicit típuskonverzió), hanem azt, hogy a konverziókra bizonyos megkötések vannak. Sajnos nincs általánosan elfogadott definíció.

Példák:
Dinamikus, gyenge: JS (és pl PHP)
Dinamikus, erős: Python
Statikus, gyenge: C
Statikus, erős: Java
85

MadBence, +:

Pepita · 2013. Szep. 28. (Szo), 22.16
Egy szoftver sosem statikus
Dehogynem. Ha változtatsz rajta, az már min. egy újabb verzió, de újra lefordítottad, telepítetted, stb. (Mármint az erősen típusos nyelveknél.)
Akkor dinamikus egy szoftver, ha képes saját magát változtatni - ez szerintem kerülendő útirány, vagy legalábbis programozás-elméleti szakemberek témaköre, nekünk, egyszerű gyakorlati fejlesztőknek erősen kockázatos vállalkozás bármilyen nyelven-környezetben.
emiatt mindenképp hátrányba kerülök
A szoftvereknek és magának az informatikának az egyik legnagyobb előnye, hogy ráterhelhetünk saját agykapacitásunk terhelése helyett olyan feladatokat, amiket nagyon sokszor kell ugyanúgy végrehajtani. És a (jó) szoftverek ebben megbízhatóbbak (kevesebb a tévedési kockázatuk) az embernél.
ezt egy nagyon merev szerkezetnek látom, ami idővel, a szoftver szükségszerű hízásával egyre nagyobb problémákat fog okozni.
Annyira merev, amennyire azzá teszed. Pont az a lényeg, hogy magukat a függőségi szabályokat is te határozhatod meg. Ezzel lehetőségeket kapsz, nem korlátokat.
És pont a szoftver "hízásakor" jutsz nagy előnyökhöz - feltéve, hogy elejétől fogva volt olyan jó a koncepciód, hogy a szükséges bővítés beleillik az előzőleg kialakított függőségekbe. (Itt van megint: "előre optimalizálunk".)
Összességében nézve hatalmas előnyökhöz jutsz, ha ügyes vagy. Pl. ha "függvénytárazol", akkor - mivel globálisak a fv-eid - "hízáskor" már nézheted is vissza az összes eddigi fv-edet, nehogy felülírj egy olyat, amit máshol meg ugyanúgy akarnál használni. Ugyanez igaz a változókra is. (Míg osztályokban akár mindegyiknek lehet ugyanolyan fv-e, de mégis kicsit mást csinál.) De ez csak a legegyszerűbb ok az OOP mellett, számos más előny is van (pl. loader_class írása / megléte), ami lényegesen megkönnyíti magát a programozást, és könnyen tudsz olyan okos struktúrát felépíteni, amivel még memóriát is spórolsz. Ugyanezt össze-vissza require_once() mindig, nagyon munkaigényes.
az OOP jellegéből adódóan a programkódba hardkódolva van az adattípusok "viselkedése"
Ezért nem igazán OOP a PHP (nekem), mert neked kell(ene) erősen típusossá tenni, ami nagy feladat, valóban. De egyébként számos előnye is van a típusosságnak:
- "helyettet" részben ellenőrzik a bevitt adatokat (nem kell pl. is_int(), de persze a kivételt "illik" kezelni;
- kapásból "passzol" a változód az adatbázisod megfelelő mezőjével;
- nem vesztesz egy csomó időt a legkülönbözőbb helyeken az automatikus típuskonverziókkal.
90

Ha változtatsz rajta, az már

Hidvégi Gábor · 2013. Szep. 29. (V), 15.00
Ha változtatsz rajta, az már min. egy újabb verzió, de újra lefordítottad, telepítetted, stb. (Mármint az erősen típusos nyelveknél.)
Maradjunk a webnél, ahol a többség scriptnyelveken programoz; ebből a szempontból a Java is kisebbségben van (számomra). Ha szoftvert írok, akkor is weboldalra vagy webes alkalmazásra utalok.

És a (jó) szoftverek ebben megbízhatóbbak (kevesebb a tévedési kockázatuk) az embernél.
Mitől jó egy szoftver? Mitől megbízhatóbb? A nagy szoftverházak is úgy adják ki programjaikat, hogy tele vannak hibával, és a felhasználók az igazi teszterek, aztán előbb-utóbb javítják ezeket.

feltéve, hogy elejétől fogva volt olyan jó a koncepciód, hogy a szükséges bővítés beleillik az előzőleg kialakított függőségekbe
Feltéve, ha ... Tapasztalatom szerint az eredeti elképzelésnek sosem felel meg a végleges szoftver, mert a megrendelő mindig kér ezer változtatást, ráadásul menet közben derül ki számtalan esetben, hogy valamire nem gondoltunk a tervezés során.

Összességében nézve hatalmas előnyökhöz jutsz, ha ügyes vagy.
Ismét egy bizonytalan pont.
123

Mitől jó egy szoftver? Mitől

inf3rno · 2013. Szep. 30. (H), 01.17
Mitől jó egy szoftver? Mitől megbízhatóbb? A nagy szoftverházak is úgy adják ki programjaikat, hogy tele vannak hibával, és a felhasználók az igazi teszterek, aztán előbb-utóbb javítják ezeket.


Javaslom, hogy nézz utána a TDD témakörének. Egy így fejlesztett szoftver jóval megbízhatóbb, mint egy, csak úgy a levegőbe írt kód, aminél az if egyik ágát sosem tesztelte senki, mert nem volt kedve a fejlesztőnek annyit kattintgatni. Plusz unit tesztekkel a későbbi módosítások sem okoznak törést a kódban. Akár struktúrált kódot is fejleszthetsz így.
128

Ott is ugyanúgy

Pepita · 2013. Szep. 30. (H), 02.14
a többség scriptnyelveken programoz
Annyi a különbség, hogy kb. minden oldalkéréskor lefordul. De ettől még ha változtatsz: az egy újabb verzió.
Mitől jó egy szoftver? Mitől megbízhatóbb?
Pont attól, hogy megvalósítja a specifikációt. És ha ezt egyszer megtette, akkor amíg nem változtatsz rajta / el nem száll a szerver, addig kvázi akárhányszor végrehajtja neked ugyanazt, míg az ember egyszer csak elfárad, hibázik. Ha másként gondolod, akkor ne haragudj, de inkább papír-írószerrel érdemesebb foglalkoznod. A szoftverek (bármilyen) lényege elsősorban az automatizálás. Persze lehet ezt rosszul is csinálni, akkor végtelenszer fogja rosszul végrehajtani a feladatot.
Tapasztalatom szerint az eredeti elképzelésnek sosem felel meg a végleges szoftver, mert a megrendelő mindig kér ezer változtatást, ráadásul menet közben derül ki számtalan esetben, hogy valamire nem gondoltunk a tervezés során.
Így igaz. Jó tervezéssel - amihez megfelelő interjú és alany is kell - a munkád nagyobbik részét el is végezted. Minél több hiba van a tervezésben, annál többet kell majd javítani is. Pont a megrendelő új igényei miatt (amik valóban nagyon valószínűek) kell olyan struktúrát felépíteni, ami könnyen bővíthető (ebben (is) van az OOP nagy segítségedre, ha ki tudod használni).
Ismét egy bizonytalan pont.
Már ne haragudj, de bármelyik szakmában ha ügyetlen vagy (akár hólapátolásban is), akkor mindig "megfájdul a derekad". Az OOP csak egy lehetőség, hogy ügyes légy. Ha nem tudod, akkor nem használod, lesz belőle néhány derékfájás.
Sokkal inkább készíthető könnyen továbbfejleszthető szoftver OOP szemlélettel, mint anélkül. Én teljesen autodidakta módon fogtam OOP-be (Delphi), vért izzadtam, mire elkezdtem az előnyeit felfogni. Addig bűn ronda kódot írtam, kilométeres függvényekkel, stb. Aztán elkezdtem szétválasztani a részfeladatokat, stb...
Ezzel együtt, amit fentebb írtál: olyan hosszú egy fv., amilyen kell, azzal részben egyet is értek. Nekem valahol ott a középút, hogy annyira azért nem "cleancode-olok", mint pl. inf3rno (pedig elméletben egyetértek vele), mert minden egyes interfész +1 stack-művelet is egyben, emiatt - erőforrás spórolása okán - van néha hosszabbacska fv-em is. De ezzel máris aláásom a továbbfejleszthetőséget, tehát nagyon csínyán kell bánni vele.
129

minden egyes interfész +1

Joó Ádám · 2013. Szep. 30. (H), 02.18
minden egyes interfész +1 stack-művelet is egyben


Vagy nem, mert a fordító inline-olja.
131

Nyelvfüggő

Pepita · 2013. Szep. 30. (H), 03.14
Nincs konkretizálva a nyelv, te melyik(ek)re mondod?
133

Akármelyikre, az egyik

Joó Ádám · 2013. Szep. 30. (H), 03.36
Akármelyikre, az egyik legalapvetőbb optimalizáció.
134

Gyerünk aludni

Pepita · 2013. Szep. 30. (H), 03.45
Ha ennyire felejtek...
130

Az tévhit, hogy attól, hogy

inf3rno · 2013. Szep. 30. (H), 02.29
Az tévhit, hogy attól, hogy kevesebb a függvény meg az osztály lényegesen gyorsabb lenne a kód. Nem ez szokott lenni a szűk keresztmetszet. Szerver oldalon a fájl és adatbázis műveletek, kliens oldalon meg a http kérések, a dom fa építése, ilyesmik...
132

Lehet

Pepita · 2013. Szep. 30. (H), 03.22
Igazad van, megint kicsit elkanyarodtam a webtől. Alapból én assemblyben gondolkodom mindig (bip-bip); szerver oldalon inkább az adatbázisból kinyert adatok PHP-val rendezése, template, stb. Maga a lekérdezés általában gyors (ha nem Pistike írta).

De olyan értelemben pontatlanul "idéztél", hogy nem a kevesebben van a hangsúly, hanem a mélységen. Tehát az örökíted az örökíted a,.... A másik, hogy ha fv1-ből hívod f2-őt, amiből fv3-at... és mikor mindenki a mélységi sorban visszatért, akkor fejeződik be fv1 az eredménnyel. Ez független a fájlkezeléstől, bár ha az rendszeres, akkor amellett elenyésző idő, de nem elenyésző RAM / CPU.
135

Ja, nyilván egy olyan kódnak,

inf3rno · 2013. Szep. 30. (H), 04.06
Ja, nyilván egy olyan kódnak, ahol rendesen szét vannak választva az absztrakciós szintek, sokkal nagyobb a mélysége. Nem értek olyan nagyon az optimalizáláshoz, nem tudom, hogy az mekkora plusz költséggel jár. Gyenge gépekre írt asztali alkalmazásoknál problémát okozhat, nagyobb alkalmazásoknál viszont annyi előnye biztosan van, hogy két jól megválasztott absztrakciós szint közé bármikor be tudsz tenni egy-egy új számítógépet, cache-t, bármi mást, tehát sokkal jobban skálázható, mint a spagetti kód...
137

Ha megnézel különféle

tgr · 2013. Szep. 30. (H), 09.06
Ha megnézel különféle benchmarkokat, akkor általában pár száz órajel (azaz néhány tized nanoszekundum) köré hozzák ki egy függvényhívás költségét. Ha webalkalmazásoknál maradunk, egy oldal legenerálása még egy gyors, jól megírt honlapon, adatbázisműveleteket elkerülve is ~100ms nagyságrendű, vagyis mondjuk 10ms az a sebességváltozás, amit már észreveszel. Ez úgy pár tízmillió függvényhívással hozható össze. Még egy nagyon túltervezett alkalmazásról is nehezen tudom elképzelni, hogy mondjuk tízezernél több függvényhívás történne egy request során (ilyenkor ugye 1us nagyságrendű többletidőről beszélünk). Szóval ez teljes mértékben álprobléma, ha nem mondjuk 3D render engine-t írsz éppen.
147

Én sem írtam az ellenkezőjét,

inf3rno · 2013. Szep. 30. (H), 18.20
Én sem írtam az ellenkezőjét, csak azt, hogy nem tudom, mert sosem mértem. Ettől függetlenül még fennáll az az előny, hogy absztrakciós szintek mentén bármikor el lehet hasítani az alkalmazást, és átteni új gépekre a kód egyik - másik felét, ha nő a terhelés. Az n-tier architecture gondolom elég elterjedt nagy rendszerek esetében, nem folytam bele jobban a gyakorlati részébe...
141

»Tapasztalatom szerint az

Hidvégi Gábor · 2013. Szep. 30. (H), 09.53
»Tapasztalatom szerint az eredeti elképzelésnek sosem felel meg a végleges szoftver, mert a megrendelő mindig kér ezer változtatást, ráadásul menet közben derül ki számtalan esetben, hogy valamire nem gondoltunk a tervezés során.«
Így igaz. Jó tervezéssel - amihez megfelelő interjú és alany is kell - a munkád nagyobbik részét el is végezted.
És
Már ne haragudj, de bármelyik szakmában ha ügyetlen vagy (akár hólapátolásban is), akkor mindig "megfájdul a derekad".
Mi számít jó tervezésnek? Mitől leszel ügyes? Példa: megkérünk egy villanyszerelőt és egy belsőépítészt, hogy modellezzen egy házat. Mindketten más nézőpontból fogják ezt megtenni, a belsőépítész valószínűleg mint szobák sorozatát látja, a villanyszerelő pedig mint falak és padlók egymáshoz kapcsolódó összességét. A falakat mindketten látják, de másképp, más prioritással kezelik és más összefüggéseket vonnak közöttük. Ki oldja meg jobban a feladatot? Melyikük az ügyesebb? Ügyetlen-e a másik?
148

Amit egy oo alkalmazásnál

inf3rno · 2013. Szep. 30. (H), 18.27
Amit egy oo alkalmazásnál tervezni kell az az api, meg esetleg az adatbázis struktúra. Minden mást ki lehet tölteni tdd használatával. Ha nem így fejleszt az ember, akkor nagyon könnyen overengineering lehet a vége.
152

Szerintem TDD-ben az API is

Joó Ádám · 2013. Szep. 30. (H), 18.43
Szerintem TDD-ben az API is organikusan fejlődik.
153

Mire gondolsz? Nálam az van,

inf3rno · 2013. Szep. 30. (H), 18.48
Mire gondolsz? Nálam az van, hogy van egy specifikáció, hogy mit kell tudnia az alkalmazásnak, az alapján csinálok egy api-t, aztán abból meg tdd-vel implementálom az egészet. Esetleg ha nem rest-ről van szó, és többféle megjelenítési mód van, akkor középen el lehet vágni, és bele lehet tenni egy model api-t, amit a többféle megjelenítés használ, a view részét meg már annyira nem szokás tesztelni, mert nem éri meg.
154

API alatt most nyilvános,

Joó Ádám · 2013. Szep. 30. (H), 18.52
API alatt most nyilvános, REST API-t értesz, vagy az osztályinterfészeket?
155

Ja, REST api-ra gondoltam.

inf3rno · 2013. Szep. 30. (H), 19.28
Ja, REST api-ra gondoltam. Fentről szokás elkezdeni fejleszteni, aztán feladatkör szerint tovább darabolni. Egy sima webalkalmazás már zűrösebb, mert ott html kimenet kell, meg űrlap bemenet, szóval azt talán jobb a model-nél elkezdeni tesztelni.
88

Egy statikus típusrendszer

Joó Ádám · 2013. Szep. 29. (V), 12.51
Egy statikus típusrendszer minden kifejezéshez típust rendel.

Ezek az annotációk jól dokumentálják a kódot, és mindig naprakészek, szemben a kézikönyvvel vagy akár a kommentekkel, mert a fordító gondoskodik róla, hogy azok legyenek.

Ennél sokkal fontosabb, hogy fordítási időben kiderül, ha értelmetlen műveletet végzel, ezért soha nem fordulhat elő, hogy futási időben egyszercsak olyasmi történik, amivel a futtatókörnyezet nem tud mit kezdeni, mondjuk beleindexelsz egy logikai változóba (az egy null kivételével, ami egy csúnya rés a típusrendszeren, és a futásidejű hibák talán legnagyobb részéért felel).

Ez utóbbinak egy felbecsülhetetlen értékű gyakarlati következménye, hogy bármilyen módosítást végzel a kódban, mire kijavítasz minden fordítási hibát, garanciád van rá, hogy a kódod ismét helyesen működik. Tehát éppen az ellenkezője igaz annak, amit írsz: egy statikus típusrendszerrel sokkal gyorsabban tudod a kódodat a változó igényekhez igazítani, mert a helyes működés ellenőrzését automatizálja.

Az én személyes tapasztalatom, mióta statikus nyelvekre váltottam, hogy ha lefordult a kódom, gyakorlatilag biztos lehetek benne, hogy helyesen működik.
60

OOP nélkül is lehet kiváló

inf3rno · 2013. Szep. 15. (V), 23.33
OOP nélkül is lehet kiváló programokat készíteni

Persze, hogy lehet, csak nehezebb...
7

Ne tedd.

bamegakapa · 2013. Szep. 10. (K), 18.57
Inkább tanulj meg angolul, anélkül úgyse jutsz semmire ebben a szakmában.