ugrás a tartalomhoz

Legnehezebb feladat PHP-val

Szita Szilárd · 2013. Okt. 10. (Cs), 15.57
Nektek eddig mi volt a legnehezebb feladat amit PHP-val oldottatok meg? Nekem eddig egy belépés létrehozása, de az is televolt biztonsági hibákkal :)
‹ Panoramio képek lekérdezése PHP verzióinak követése..? ›
 ■
1

Valamelyik

janoszen · 2013. Okt. 10. (Cs), 16.00
Nem tudok donteni:

1. 1 millio kodsoros projekt karbantartasa.
2. Elosztott halozati protokollon mukodo elszamolasi rendszer fejlesztese.
2

Idézet

Szita Szilárd · 2013. Okt. 10. (Cs), 16.02
1. 1 millio kodsoros projekt karbantartasa.

Milyen funkciókat tartalmazott?
3

Szerintem ne kérd

Pepita · 2013. Okt. 10. (Cs), 17.27
arra, hogy azt a kb. 10000 funkciót felsorolja...
10

Titoktartas

janoszen · 2013. Okt. 11. (P), 00.59
Gondolom eleg egyertelmul, hogy ez eroteljesen a titoktartas hatalya ala esik. Annyit elmondhatok, hogy baromi komplex elszamolasi rendszer volt.
13

P2P PHP alapon? Ez elég

tgr · 2013. Okt. 11. (P), 08.39
P2P PHP alapon? Ez elég durván hangzik :)
4

Ha nem is feladat...

Pepita · 2013. Okt. 10. (Cs), 17.31
- Megszokni a gyengén típusosságot (úgy, hogy közben ne lustuljak el) - máig nem teljes;
- A fenti miatt "sajátos" OOP
- Különböző IDE-k többé-kevésbé működő kódkiegészítése
- Időzónák-időpontok helyes kezelése, főként úgy, hogy az adatbázisszerver rendszerint "külön szobában lakik".

Mindezekben legnagyobb segítséget a WL cikkek, illetve fórum jelentett.
5

Korrekt

Szita Szilárd · 2013. Okt. 10. (Cs), 17.36
Feladatok :)
Én is akarok valami feladatot, tudsz valami egyszerűt?
gyakorlásnak
6

Mi az egyszerű?

Pepita · 2013. Okt. 10. (Cs), 20.04
Hol tartasz most?
Fájlkezelés profin megy?
Session?
OOP?
Adatbázis?
Framewrkot használsz?
Melyiket, miért azt?
Most akarsz ismerkedni velük?
Template?

Ezekkel mind lehet mit gyakorolni, de sorjában. Illetve alapfeltétel, hogy HTML-CSS erős jó szinten, JS legalább valamelyik (pl. jQuery) keretrendszerrel jól menjen. Utána érdemes backend-ezni, mert jó kimenetet csak ezek ismeretében tudsz gyártani.

A kérdések nem biztos, hogy a legjobb sorrendben vannak, de az alapján lehet, hogy te is ki tudsz találni feladatokat. Javaslom az itteni cikkeket is, régiek közt is rengeteg van, ami ma is megállja a helyét.
14

Bővebben

Szita Szilárd · 2013. Okt. 11. (P), 12.34
Most hol tartok szinte sehol, de egy picit részletsebben.
Fájlkezelés profin megy?

Nem foglalkoztat ez a téma tehát maximálás tudás:Olvasás,Írás
Session? munkamenet

Igazából ebbe rengeteg hibám van készítettem egy belépés modult és ott rengeteg hiba volt.
OOP?

Egyáltalán nem megy, nem tudom megérteni az egésznek a lényegét.
Adatbázis?

Írás,Olvasás,UPDATE


A többiről meg ne is beszéljünk, mert szinte nulla angoltudással, semmi esély ilyeneket megtanulni.
Lehetséges, hogy elsőnek az angolra kéne koncentráljak?
15

Angol, OOP

Gixx · 2013. Okt. 11. (P), 15.20
Az angol sajnos elkerülhetetlen. Csak magyar forrásokból összeszedni minden tudást elég nehéz lesz, hanem egyenesen lehetetlen. Alapozni lehet vele, vannak jó könyvek, de valós problémákra munka közben legkönnyebben angolul fogod megtalálni a választ.

OOP: nekem is nehezen ment anno felfogni az OO lényegét. Aztán azt javasolta nekem egy ismerősöm, hogy próbáljam meg a körülöttem lévő világot objektumokként kezelni. Nem garantálom, hogy teljesen helyes a példám, majd a többiek korrigálnak :)

Vegyünk például egy 2013-as évjáratú, piros színű, Suzuki SX4-et.

Példány: ez a konkrét autó.

Osztály: ez az autó a "2013-as Suzuki SX4" osztály egy példánya.

Öröklődés: feltehetőleg a "2012-es Suziki SX4" osztályból származik. Sok mindent átvesz belőle, van, amit javít, és vannak újdonságok is. A legeslegelső Suzuki SX4 viszont egy nem példányosítható, absztrakt osztály: a terv.

Interfész implementáció: ha az új dolgokat egy szabvány írja le, ez a szabvány lehet akár egy Interface osztály. Amelyik autó ezt az interface-t implementálja, kötelezően meg kell felelnie a szabványnak is. Több ilyen szabványt is implementálhat egyszerre (végülis az összes szabványt fel lehet sorolni).

Példányosítás (konstruktor): lejön a gyártósorról.

Destruktor: bezúzzák a roncstelepen.

Publikus osztályváltozó pl.: az autó színe. Lehet az alapértelmezett (azt hiszem mindegyik alapból fehér, csak később festik át), lehet a példányosításkor megadott, de akár futásidőben is változhat (lásd taxi matricázási mizéria).

Privát osztályváltozó: ezt nem örökli az őstől, és nem is örökíti tovább, ez csak erre az osztályra és annak példányaira jellemző, és kintről nem érhető el közvetlenül. Ez valami belső tulajdonsága az autónak, ami kaphat alapértelmezett értéket is, de példányonként változhat is a példányosítást követően. Pl az tipus családra jellemző sorozatszám: "2013SSX4HU". A szakszervízben megfelelő eszközzel, publikus metódusok révén lekérhető :D

Protected osztályváltozó: Ezt örökli az őstől, a többi szempontból ugyanaz, mint a privát.

Osztály konstans: minden példányban ugyanaz, és nem változik. pl évjárat.

Statikus osztályváltozó: a beállított értéke az osztály minden példányára vonatkozik, ha az egyikben változik, mindben változik. Pl a fedélzeti navigációs szoftver frissítő csomagja, bár nem hiszem, hogy a Suzukinál van ilyen központilag vezérelt frissítés. Talán inkább a Merciknél :)

Publikus metódusok: pl. autó indítása. Megpróbálod (try) beindítani és az autó elindul. Vagy dob egy kivételt és azt kezelni kell (catch): káromkodsz.

Protected metódusok: öröklött funkció, de nem közvetlenül felhasználói interakcióval lép működésbe, hanem belsőleg hívja meg valami. Pl az üres tankot jelző lámpácska bekapcsol, ha kevés a benzin.

Privát metódusok: nem öröklött funkció, de minden példányban szerepel. Pl.: ha új funkcióként kerül be az esőérzékelő, akkor ha víz éri a szélvédőt, az elindítja az ablaktörlőt. De rájönnek, hogy ez gagyi, így a 2014-esben már nem lesz benne (nem örökli).

Statikus metódusok: példányosítás nélkül is meghívhatóak. Na ez mondjuk mi lehet... Mondjuk az ára. Még nincs is kész egy példány se, de már tudjuk, mennyibe fog kerülni.

Final osztály: vagy elérte az abszolút tökéletességet, vagy egy műszaki zsákutca. A lényeg, soha többet nem lesz több Suzuki SX4 osztály, de legalábbis ebből az osztályból biztosan nem fog leszármazni más.

Kivételkezelés: ha mondjuk vezetés közben az autó dob egy kivételt, pl.: durrdefekt, azt vagy elkapja (catch) még belsőleg (pl.: a defekt-mentes gumi felfújja magát), vagy kigyűrűződik a "hívó fél" (sofőr) felé. Ha a hívó fél se kapja el (higgadtan megáll, majd kerékcsere), akkor kimegy a legkülső szintig (fa, természet, világ), és ott dob egy fatális hibát (kampec), és meghívódik a destruktor, meg a halottkém :)
16

Nagyon szemléletesen

Hidvégi Gábor · 2013. Okt. 11. (P), 16.18
Nagyon szemléletesen összeszedted a dolgokat. Viszont minden éremnek két oldala van, emiatt lennének kérdéseim: Milyen hátrányai vannak az OOP-nek? Milyen feladatokra nem alkalmas? Mik a buktatói, mire kell figyelni? Milyen alternatívákat tudsz ajánlani? A helyes döntéshez ezek megválaszolására is szükség van, hisz minden feladathoz a megfelelő eszközt kell használni.
17

A buktatóknak vagy másik

Joó Ádám · 2013. Okt. 11. (P), 16.35
A buktatóknak vagy másik oldalról nézve annak, hogy hogyan tervezz minél fenntarthatóbban objektumorientált kódot, könyvtárnyi irodalma van. A fősodorbeli programozási feladatokra mind alkalmas, ezért az alternatívákat elég akkor megkeresni, amikor erre szükség van, ekkor pedig az ember már nem kezdő, és tudja, hogy mit miért csinál.
18

A buktatóknak vagy másik

Hidvégi Gábor · 2013. Okt. 11. (P), 16.53
A buktatóknak vagy másik oldalról nézve annak, hogy hogyan tervezz minél fenntarthatóbban objektumorientált kódot, könyvtárnyi irodalma van.
Tudnál ajánlani pár jó írást?

A fősodorbeli programozási feladatokra mind alkalmas
Mi tartozik a fősodorhoz és mi nem? Milyen más programozási metódus alkalmas még ezekre a feladatokra?

alternatívákat elég akkor megkeresni, amikor erre szükség van
Ha egész életedben csak OOP-vel programoztál, hogyan ismerheted fel, mikor van szükség másfajta szemléletre?

ekkor pedig az ember már nem kezdő, és tudja, hogy mit miért csinál
Idéznék Gixx-től:
OOP: nekem is nehezen ment anno felfogni az OO lényegét.
19

Tudnál ajánlani pár jó

Joó Ádám · 2013. Okt. 11. (P), 18.32
Tudnál ajánlani pár jó írást?


Nem tartom számon az ilyesmiket, mások biztos tudnak ajánlani. Az igazán klasszikus könyvek és szerzők (például Design Patterns) úgyis szembejönnek.

Mi tartozik a fősodorhoz és mi nem? Milyen más programozási metódus alkalmas még ezekre a feladatokra?


A fősodorhoz általában üzleti célú, adatbáziskezelést végző, szervereken, asztali gépeken, és egyre inkább mobileszközökön futó alkalmazások tartoznak. Nem tartoznak ide a hardverközeli, tudományos vagy erősen párhuzamos alkalmazások. Hogy milyen más metodológia alkalmas még ezekre a feladatokra? Ha alkalmas alatt azt értjük, hogy megvalósítható, akkor bármelyik; ha azt, hogy legoptimálisabb (a kód fenntarthatósága és teljesítménye közt), akkor egyik sem.

Ha egész életedben csak OOP-vel programoztál, hogyan ismerheted fel, mikor van szükség másfajta szemléletre?


A programozást nem objektumorientáltan kell kezdeni, mert az egy összetett, különböző korábbi paradigmákból építkező szemlélet. Először ezeket kell megérteni, és ezekből áll majd össze. Ha érted, hogy hogyan épül fel, akkor később, amikor rendhagyó követelményeknek kell megfelelj, akkor tudod, hogy mit hagyj el (például hardverközeli kódoláskor), vagy éppen mit szigoríts tovább (például párhuzamos programozáskor).

Az utolsó két idézetednél nem látom az ellentmondást.
28

Idéznék Gixx-től: OOP: nekem

BlaZe · 2013. Okt. 12. (Szo), 09.31
Idéznék Gixx-től:
OOP: nekem is nehezen ment anno felfogni az OO lényegét

A kulcs a gyakorlat, és a rossz hír, hogy ezt sehogy nem lehet megúszni. Ahogy annak idején meg kellett tanulni az alapvető vezérlési szerkezeteket, meg kellett tanulni ciklust, függvényt írni, unitokba/libekbe stb szervezni a kódunkat, úgy kell ezt is megtanulni, megérteni. Nem ördögtől való, és nem megtanulhatatlan. Sőt, igazából közelebb is áll az emberi gondolkodásmódhoz, ha már beépült az eszköztárba. Kicsit talán erőltetettnek fog hatni, de amíg a strukturált programozásban műveletek, vagy ha úgy tetszik cselekvések egymás utáni sorát írod le, addig az OOP ezekhez a műveletekhez entitásokat rendel, amiken értelmezzük magukat a műveleteket, valamint ezen entitások különböző dimenziójú, típusú kapcsolatát írja le, amibe beletartozik az örökléstől kezdve a használaton át a tartalmazásig minden, amit ismerünk. Ezt a gondolatmenetet követve - ahogy Ádám is többször leírta már -, nem valódi problémafelvetés az, hogy aki OOP-ben gondolkodik, elveszíti a struktúrált gondolkodás képességét. Hiszen az OOP-ben is használjuk a strukturált programozás gyakorlatilag minden elemét, csak azt kiterjesztve még egyéb dimenziókban is enged gondolkodni és kódot szervezni. Így a kérdés fordítva áll. Aki csak strukturáltan programozik, hogyan tudna OOP-ben gondolkodni és felmérni azt, hogy neki mikor van inkább arra szüksége...?

Könyvnek pedig én is a Design patternst ajánlom.
29

Sőt, igazából közelebb is áll

Hidvégi Gábor · 2013. Okt. 12. (Szo), 10.30
Sőt, igazából közelebb is áll az emberi gondolkodásmódhoz, ha már beépült az eszköztárba.
Egy kis ellentmondást érzek abban, amit írsz: ha az OOP közelebb áll az emberi gondolkodásmódhoz, miért van az, hogy egyeseknek (például nekem) nagyon nehezen megy felfogni a lényegét? Miért szükséges hozzá gyakorlat, ha közel áll az emberi gondolkodásmódhoz?
31

Mert jellemzően az OOP sokkal

BlaZe · 2013. Okt. 12. (Szo), 11.33
Mert jellemzően az OOP sokkal több absztrakciós szintet használ, és a gyakorlati életben ezek rutinból működnek. De ha elkezded részletesebben elemezni azt amit csinálsz, mindjárt kitűnik, hogy az OOP sokkal közelebb van a valódi világ modellezéséhez, mint a strukturált. Illetve az is, hogy minden egyes cselekvésed sok kis apró részletből áll, amik az egyes végrehajtások között különbözhetnek, mégis magasabb absztrakciós szintről tekintve ugyanannak felel meg. Pl beülsz egy étterembe, és kérsz egy marhapörköltet. Ahány étterem, annyiféleképpen fogják ezt megcsinálni. De te csak egy marhapörköltet rendeltél, nem írtad le neki hogy pontosan melyik elkészítési módot kövesse, ezt rábízod a szakácsra. Ez az OOP féle megközelítés. Az étterem interfacenek van egy createMarhaporkolt metódusa :) Strukturált programozásban ez nem igaz. Van külön függvény a paprikát elején beletévős, a borral felfőzős stb. Képzeld ha úgy rendelnéd a pörköltet, hogy a pontos végrehajtási módot adnád meg a pincérnek, nem csak annyit, hogy pörköltet kérsz...

És hogy miért szükséges hozzá gyakorlat? Mert az életben mindenhez kell. A pörkölt elkészítéséhez is :)
37

Ez nem teljesen igaz,

inf · 2013. Okt. 12. (Szo), 12.46
Ez nem teljesen igaz, struktúráltan is lehet createMarhapörkölt(étterem, szakács) függvényt írni, csak bonyolultabb dolgoknál minden egyes paramétert át kell adni, ami egy idő után gondolom agyérgörcsöt okoz, vagy valami objektum szerű struct típusú dolgok készítéséhez vezet, ami már majdnem az oop.
45

Ez a lényeg. Az

Joó Ádám · 2013. Okt. 12. (Szo), 20.24
Ez a lényeg. Az objektumorientáltság nem valami lepárolható dolog. Nincs éles határ a jó strukturált és az objektumorientált programozás közt. A klasszikus procedurális programozás és az objektumorientáltság közti leglényegesebb szemléletbeli különbség az adatok lokalizálása specifikus típusokba ahelyett, hogy külső változókat (argumentumokat, szabad változókat vagy globálisakat) állítgatnának az eljárások. Az összes többi már részletkérdés.
52

A clean code-ban elég

inf · 2013. Okt. 13. (V), 00.03
A clean code-ban elég világosan le van írva a különbség a két megközelítés között.

off: tök érdekes, úgy emlékszem, hogy magyarul olvastam azt a könyvet, pedig biztos, hogy angolul, fura dolgok ezek :D

on: Van benne egy teljes fejezet objects and data structures címen. Van egy elég jó példa benne geometriai alakzatokkal. Kb úgy néz ki a dolog, hogy vannak alakzatok, pl kör, négyzet, stb... Ezeket kirajzoljuk egy render nevű függvénnyel.

Az oo megközelítés:

interface Shape {
    function render();
}
class Circle implements Shape {
    //...
}
class Rectangle implements Shape {
    //...
}
//...
A struktúrált megközelítés:

class Shape {}
class Circle extends Shape {
    //...
}
class Rectangle extends Shape {
    //...
}

function renderShape(Shape $shape){
    if ($shape instanceof Circle){
        //...
    }
    else if ($shape instanceof Rectangle){
        //...
    }
    //...
}
Tegyük fel, hogy több ilyen alakzat manipuláló függvény van. Ha hozzáadunk egy új alakzatot, akkor az objektumorientált megközelítésnél egy új osztályt kell létrehozni, és implementálni benne a Shape interface-t, ezzel szemben a struktúrált megközelítésnél ilyenkor az összes létező függvényt ki kell egészítenünk az új alakzattal. (Ezt hívják polimorfizmusnak szakszóval.) Szóval oo megközelítéssel könnyebb új típust hozzáadni. Ha viszont új függvényt akarunk hozzáadni megfordul a helyzet, ilyenkor oo megközelítésnél az összes osztályt módosítanunk kell, a struktúrált megközelítésnél viszont csak egy új függvényt kell létrehoznunk, semmi több teendőnk nincs. Szóval struktúrált megközelítéssel könnyebb új függvényt/viselkedésmódot hozzáadni. Ez az aszimmetria az adatrejtés miatt alakul ki, ami oo sajátság. Ha elrejtjük az adatot, akkor tudunk egységes interface-t csinálni az osztályainknak, ha nem rejtjük el, akkor viszont képtelenség ilyesmit létrehozni, mert minden alakzatot más-más adatokkal tudunk leírni. Pl egy kört a középpontjával és a sugarával, egy négyzetet a bal felső sarkával és a szélességével, stb... Mindkét megközelítés hasznos lehet bizonyos esetekben, ezért mindig mérlegelni kell, hogy melyiket érdemes használni, és melyiket nem. A kettő kizárja egymást, ha kevert megközelítéssel próbálkozunk, akkor mindkettő hátrányát egyesítjük, szóval mind új típust, mind új viselkedést nehéz lesz hozzáadni a kódunkhoz...
53

A polimorfizmus az, ami az

Joó Ádám · 2013. Okt. 13. (V), 01.25
A polimorfizmus az, ami az objektumorientáltság, mint önálló, új paradigma hozzájárulása a programozáshoz. Az összes többi elv, amiből az OOP építkezik, már korábban is létezett, többek között az adatrejtés is. Ezért írtam, hogy ezek csak technikai részletek, a kétfajta megközelítés (a klasszikus procedurális és az objektumorientált, akár polimorfizmust nem ismerő nyelvben is) alapvető különbsége az, hogy az egyik a vezérlésátadásokkal elért globális állapotátmenetek, míg a másik absztrakt adattípusok kezelése köré szervezi az alkalmazást. A polimorfizmus csak egy eszköz, ami – ahogy te is bemutattad –, nagyban segíti a fenntartható objektumorientált fejlesztést.
54

Ja, csak nem akartam ennyire

inf · 2013. Okt. 13. (V), 08.18
Ja, csak nem akartam ennyire elméleti lenni, azt hiszem meg se tudtam volna így fogalmazni, mert nincs meg a szótáram hozzá... A lényeg, hogy a két megközelítés kizárja egymást, ami elég nyilvánvaló abból is, amit te írtál... Nem lehet egyszerre két dolog köré szervezni a kódot, különben egy rohadt nagy káosz lesz... Btw design patterns-ben mindkettőre vannak példák, pl a Visitor ha jól emlékszem struktúrális megközelítést használ; ha van, akkor method overriding-al csinálják, ha meg nincs, akkor ugyanígy típusonként if-else ággal... Persze lehet mindent struktúrálisan, meg mindent objektum orientáltan, de egyik sem az "ultimate solution" minden problémára. Általában azt használjuk, ami az adott helyen célszerűnek tűnik... Pl az adatbázis használatánál elég világos, hogy nem az adatrejtés a cél, szóval ott a struktúrált megközelítés elég jól használható... Ugyanígy sablonok használatánál szintén... Mondjuk egy adatbázis kapcsolatnál már más a helyzet, ott az objektum orientált megközelítés a nyerő, mert senki sem kíváncsi, hogy milyen adatbázishoz csatlakoztunk milyen felhasználói névvel, vagy pl egy sablon rendszernél szintén senki nem kíváncsi rá, hogy milyen regex mintát használunk a sablon fájl parsolására, vagy mi a neve annak a sablon fájlnak, amit éppen beolvastunk...

Ha már itt tartunk továbbra sem értem, hogy Hidvégi Gábor pontosan mit javasol ezzel kapcsolatban... Hogy ne használjunk osztályokat, vagy hogy csak struktúrális megközelítéssel írjunk kódot?

Nyilván osztályokat kényelmesebb használni, mint csak függvényeket, mert minden IDE-ben meg vannak támogatva refactoring, auto completion, stb... funkciókkal, illetve pl php-ben csak rájuk van autoload, kézzel meg senki nem szeret fájlokat includolni, én legalábbis nem... Szóval az osztályok használatát szerintem legjobban az indokolja, hogy sokkal jobban meg vannak támogatva eszközökkel a csak függvény alapú programozáshoz képest, illetve csökkenteni lehet velük az átadott paraméterek számát, tehát pl struktúrált megközelítésnél ugyanúgy lehet használni őket mondjuk asszociatív tömb, struct vagy ilyesmik helyett...

A csak struktúrális megközelítést már fentebb leírtam, hogy miért nem jó. Új adattípus hozzáadásánál hátrányosabb, mint az oo megközelítés, így olyan esetekben, amikor ez előfordul, jobb inkább oo-val leprogramozni. A struktúrális megközelítés tipikusan adatközpontú dolgoknál lehet hasznos, ahol fontos az adat láthatósága. Pl adatbázisból érkező adatok, dom manipuláció, esemény kezelés, ilyesmik. Szóval csak struktúráltan programozni sem egy követendő példa, mert az ember csak a saját dolgát nehezíti meg...
49

ne már..

szabo.b.gabor · 2013. Okt. 12. (Szo), 21.54
milyen hátrányai vannak a funkcionális programozásnak az OOP-vel szemben?

egy objektumnak vannak privát változói, amiket csak rajta keresztül lehet változtatni, az objektum létrehozásakor inicializálódnak. az objektumnak "van egy állapota".

ezt a funkcionális programozás nem tudja biztosítani. el lehet érni ugyanazt a működést, de figyelned kell rá, bárki más hozzányúl a kódhoz simán elrontja két pillanat alatt és neki is meg kell tanulnia feleslegesen, hogy mire vigyázzon, nehezebb a funkcionális programozás.

adatbázis kezelés.
mysqli_query('SELECT * FROM table');
ez nem fog futni minden esetben. pl ha előtte nem csatlakozol.

egy adatbázis objektum query() metódusát nem tudod úgy meghívni, hogy nincs kapcsolat, mert az objektum példányosításakor a kapcsolat felépül, ha ez nem történik meg, az objektum sem jön létre. jobb így? jobb.

lehet persze szar "OOP" kódokat írni, attól hogy valami elején ott van hogy "class" még lehet az csak simán egy függvénycsokor, aminek semmi előnye nincs a funkcionális programozáshoz képest.

ettől függetlenül az OOP igenis nyújt pluszt a funkcionálishoz képest, ahogy fentebb már írtam is.

hátránya nincs. ha úgy tetszik berakom az összes függvényt egy osztályba, értelme nincs, de ugyanott vagy, ugyanazt tudod.

bár Te személy szerint nem említetted, hogy funkcionális programozást használsz OOP helyett, csak tippeltem. érdekelne amúgy, hogy mik a rossz tapasztalataid az OOP-vel?
50

Biztos, hogy funkcionálist

Joó Ádám · 2013. Okt. 12. (Szo), 22.05
Biztos, hogy funkcionálist akartál írni és nem procedurálist?
51

Biztosan "funkcionális"-t

MadBence · 2013. Okt. 12. (Szo), 22.06
Biztosan "funkcionális"-t akartál írni? Szerintem te a struktúrált/procedúrális programozásra gondolsz.
Funkcionális nyelvekben változók sincsenek, nemhogy privát tagváltozók :)
55

Először is definiálom, mit

Hidvégi Gábor · 2013. Okt. 13. (V), 08.19
Először is definiálom, mit értek az OOP alatt: az öröklődést és a polimorfizmust. Ahogy Ádám fentebb kifejtette, az adatrejtés és egységbezárás már korábban is létezett. Kezdek arra hajlani, hogy ez utóbbiaknak lehet értelme, de mivel a forráskód nálam van, egy privát változót akkor és annyiszor írok át publikussá, amikor csak akarok.

de figyelned kell rá, bárki más hozzányúl a kódhoz simán elrontja két pillanat alatt
Pont a fentiek miatt ez nincs így, mert a forráskód nálam van. BlaZe említette, hogy Jávában ez lehetséges, de az csak egy példa, sok más helyen meg nincs így, például php-ben és js-ben.

az objektum példányosításakor a kapcsolat felépül
Ha úgy írod meg az objektum konstruktorát. Én pl. minden ilyen inicializációt beraktam a funkciok.php elejére, amit minden scriptem elején include-olok, és mindjárt van adatbáziskapcsolatom is.

mik a rossz tapasztalataid az OOP-vel?
(Tehát az OOP-n az öröklődést és a polimorfizmust értem) Az OOP-vel az a bajom, hogy rugalmatlanul képezi le a világot, mert nagyon erős a kapcsolat az adatok és az őket kezelő metódusok között. A való életben sokkal bonyolultabbak az objektumok és összefüggéseik, mint az elsőre látszik, és egyrészt nem is sikerül mindig jól lemodellezni (mi a jó modell és ki látja jól?), másrészt a kérések mindig változnak. Emiatt rengeteg plusz kör van a programozásban, mert ha át kell írni az ősosztályt, akkor minden származékos osztályba is bele kell nyúlni.

Ugyanez procedurális programozásban nem okoz problémát, mert laza szerkezetekkel dolgozom, és az adatok jelentése, szemantikája leginkább csak akkor számít, amikor el szeretném menteni őket adatbázisba. Ebben a gyorsan változó világban a procedurális megközelítéssel – tapasztalataim szerint – jóval rugalmasabban lehet dolgozni, és a változtatásokat sokkal gyorsabban lehet elvégezni, mint OOP-vel, mert nem vagyok egy előre meghatározott adathierarchiához kötve.

Tehát üzleti logikában soha nem használnék OOP-t, viszont az utóbbi hetekben sokat gondolkoztam a dolgon, meg utána is olvastam, és jelen pillanatban úgy látom, hogy a program működésében bizonyos helyeken nem jár hátránnyal: például ha többféle bejelentkezési algoritmust szeretnél implementálni és hasonló feladatoknál, amelyek viszonylag egyszerűek, és a felületük nem változik.

milyen hátrányai vannak a funkcionális programozásnak az OOP-vel szemben?
A procedurális programozásból hiányzik például az általad említett konstruktor és destruktor, azaz ezekre nekem kell ügyelni. Ezt mondjuk lehetne implementálni procedurális nyelvekben is, mint ahogy sok más nyelvi elemet, amit a felhajtás miatt már csak OOP-be tesznek be, ez csak hozzáállás kérdése a nyelvet készítők részéről.
56

Szerintem kevered az

inf · 2013. Okt. 13. (V), 08.46
Szerintem kevered az osztályok használatát és az oo és struktúrált megközelítések közötti különbséget, ami nem akkora baj, mert egészen eddig én is kevertem őket. :-)

Osztályokkal is lehet struktúrált megközelítéssel programozni, senki nem akadályoz meg benne, viszont cserébe kapsz egy csomó kényelmi funkciót, pl autoload, constructor-destructor, stb... amiket csak függvényekkel alapból nem kapsz meg. Egy picivel fentebb már leírtam példákkal is, hogy mi a különbség a két megközelítés között, és szerintem mikor melyiket érdemes használni. Ha gondolod olvasd el.
57

Olvastam, csak felületesen.

Hidvégi Gábor · 2013. Okt. 13. (V), 09.07
Olvastam, csak felületesen.
58

Közben szerkesztettem, lehet,

inf · 2013. Okt. 13. (V), 10.20
Közben szerkesztettem, lehet, hogy azért tűnik most úgy. Valahogy rászoktam az állandó szerkesztgetésre...
59

Emiatt rengeteg plusz kör van

BlaZe · 2013. Okt. 13. (V), 13.41
Emiatt rengeteg plusz kör van a programozásban, mert ha át kell írni az ősosztályt, akkor minden származékos osztályba is bele kell nyúlni.

Erre mondj egy példát, mert szerintem másra gondolsz mint amit leírtál, ugyanis ennek épp az ellenkezője az igaz. A származtatott osztályba mindig csak a felülírt és kibővített tulajdonságok és metódusok kerülnek. Emiatt az interface változtatásokat is csak odáig kell elvinni, ameddig az osztályhierarchia feltétlenül megköveteli.
60

Pont most készülünk az

Hidvégi Gábor · 2013. Okt. 13. (V), 14.47
Pont most készülünk az általam írt rendszerben egy ilyenre, egy analóg példát írok:

.
              Bankszámla
            betét - kivét
           /            \
          /              \
Megtakarítási számla   Folyószámla
     lekötés       ingyenes pénzfelvétel
       /              /              \
      /              /                \
Számlatípus C   Számlatípus D      Számlatípus E
  Featúra 5        Featúra 6         Featúra 7          
                                         \
                                          \
                                    Számlatípus F
                                      Featúra 8

Tipikus OO feladatnak tűnik, mindegyik al számlatípus örökli a felette lévő featúráit.

Egy eleve borúsan induló napon a mit sem sejtő programozó beérkezik reggel a munkahelyére, ahol a főnöke a következő feladattal lepi meg: A Számlatípus C-ből a Featúra 5-öt szeretnénk a Számlatípus F-ben is használni.

Mit tehet ilyenkor? Fogja a Featúra 5 kódját, felteszi a Bankszámla osztályba? Ekkor minden alatta lévő örökli, a Számlatípus D és E is, viszont az ezeket használó ügyfelek ilyen plusz szolgáltatást nem kaphatnak.
61

Ez a szituáció tipikusan

inf · 2013. Okt. 13. (V), 15.28
Ez a szituáció tipikusan azért alakul ki, mert nincs többszörös öröklés a nyelvben, és úgy lehet megoldani, hogy ki kell emelni külön osztályba a feature 5 kódját, és az új osztálynak a példányait kell használni a C és F típusnak. Általában ilyen esetben az SRP nem szokott teljesülni, túl sok felelősséget próbálnak ráruházni 1-1 osztályra, és ez vezet egy átláthatatlan öröklési sorhoz. A legjobb példa erre az extjs 3, ahol azt hiszem 7x-es öröklődés is volt...
63

Szerintem egyszerűbb egy

Hidvégi Gábor · 2013. Okt. 13. (V), 15.49
Szerintem egyszerűbb egy táblában leírni, hogy melyik bankszámlatípushoz melyik featúra tartozik, és máris nincs szükség bonyolult nyelvi elemekre meg örökölgetésre.
64

Ennek max akkor van értelme

inf · 2013. Okt. 13. (V), 16.05
Ennek max akkor van értelme szerintem, ha admin oldalról állítgatni kell, hogy melyik számlához milyen feature tartozzon. Ha nincs szükség ilyesmire, akkor teljesen felesleges adatbázisban tárolni, plusz még lassítja is a kódot a plusz egy adatbázis lekérdezés.

A bonyolult nyelvi elemekről annyit, hogy a new és class kulcsszavakon kívül másra egyáltalán nincs szükség hozzá, az oo programozásnál meg ezek kb első oldalon szerepelnek minden tankönyvben...
65

És nem egyszerűbb, hogy a

Hidvégi Gábor · 2013. Okt. 13. (V), 16.32
És nem egyszerűbb, hogy a menedzserek bekattintgatják maguknak az adminfelületen, milyen kombinációja tartozzon a featúráknak az egyes bankszámlákhoz, minthogy szaladgáljanak hozzád, hogy ugyan, változtasd már meg a forráskódot az épp aktuális hepp kedvéért? (Laza vs. erős kötés)
66

Ez nem laza vs erős csatolás,

inf · 2013. Okt. 13. (V), 16.56
Ez nem laza vs erős csatolás, csak az api áttervezése, és mellesleg egy teljesen új feature, aminek az alap felvetéshez sok köze nincsen. Ha gyakran előfordul ilyesmi, akkor nyilván elgondolkodik az ember, hogy be kéne szórni admin oldalra, hogy ne téged hívogassanak állandóan miatta. Szocialista munkamorál szempontjából viszont ugyanannyi fizetést kapsz, ha kézzel megcsinálod akkor is, szóval jobb csak magadnak egy admin oldalt csinálni, amivel belenyúlsz, aztán fél órát kávézol... ;-)
62

class SzámlatípusC extends

MadBence · 2013. Okt. 13. (V), 15.48
class SzámlatípusC extends MegtakaritasiSzamla implements Featura5
class SzámlatípusF extends SzamlatipusE implements Featúra5
Lenne az első megközelítés. Sajnos ez kódduplikációt okoz, szóval más irányban kell keresgélni. Egy másik ötlet lehetne a többszörös öröklés:
class SzámlatípusC extends MegtakaritasiSzamla, Featúra5
class SzámlatípusF extends SzamlatipusE, Featúra5
Ilyen sok nyelvben nem érhető el (de pl PHP-ban pont igen: traits), ez egy teljesen korrekt (és rugalmas) megoldás.

A többi nyelvben pedig mint utolsó lehetőség, a kompozíció merülhet fel:
class SzámlatípusC extends MegtakaritasiSzamla {
  Featúra5 featura5;
}
class SzámlatípusF extends SzamlatipusE {
  Featúra5 featura5;
}
Ez talán a legrugalmasabb, és a legjobban bővíthető megoldás.
20

Angol

Pepita · 2013. Okt. 12. (Szo), 00.29
Elsősorban az angol kell, azt minél jobb szinten. Bármi frameworkot, stb-t akarsz majd használni a későbbiekben, nem lesz rá magyar doksi, örülhetsz, ha angol van. Tehát doksiolvasás-megértés szintjén kell.

Gixx elég jól szemléltette neked az objektumorientáltság lényegét, de szerintem még később kéne ilyesmivel foglalkozz. (Nem derült ki a HTML, CSS, JS tudásod sem, addig nincs is értelme PHP-vel, szerveroldallal foglalkozni, amíg ezek nincsenek jó szinten.)

Az, hogy a fájlkezelés "nem foglalkoztat", nagy hiba. Csípőből ki kell listázni pl. HTML táblázatba (gyakorlásként) egy adott könyvtár fájljait (pl. csak bizonyos MIME típusút), méret, vagy dátum szerint sorbarendezve, kiírva az összes adatot róla, stb. Amint egy valamirevaló dinamikus honlapot készítesz, azonnal kell a legkülönfélébb fájlkezelés (és képkezelésről még szó sincs).

A munkamenet nem egyenlő beléptetőrendszerrel. Olvass utána mindkettőnek, itt is vannak magyar cikkek, ha jól emlékszem. Ne keverd a kettőt, persze leggyakrabban felhasználókezelésre használunk session-t, de munkamenet már akkor is van (ha jól csinálod), mikor még be sem lépett. Előbb ezzel foglalkozz (pl. látogatottság számolása), csak jóval később a felhasználókezeléssel. Ott már egy csomó biztonsági problémát is kezelni kell.
Session-nél még érdekes, hogy fájlban van-e, adatbázisban, esetleg sütiben - legalább az alap PHP-s megoldásokat ismerd meg (PHP manual, valaha volt részben magyarra fordított letölthető CHM is, keresgélj).

OOP-re ráérsz még, legyenek meg az alapok, majd utána érdemes absztrakciókkal foglalkozni.
Írás,Olvasás,UPDATE
Ha három szóban meg tudod fogalmazni, mit tudsz adatbáziskezelésből, hát akkor az elejét. Adatbázist először is tervezni kell tudni, ha azt jól csinálod, öröm lesz gyártani hozzá a lekérdezéseket. Ez nagyon feladatspecifikus, egyszerűbbtől a bonyolultabb felé haladva, sok feladat megoldása (és sok hiba miatti ALTER) után leszel jó tervező.
Ezt is nyugodtan tedd félre, amíg az alapok (fentiek) nem elég jók. És majd adatbázis-kezelés után jöhet OOP, addig szerintem csak bonyolítja a helyzeted. De azt elhiheted: nem "divatból" programozunk OO, hanem mert hasznosabb, könnyebb, hordozhatóbb, tisztább. De kellenek hozzá a jó alapok is, mint egy palota alá. Ha az alapokban lyukak vannak, az egész összedől.

Itt egy kicsit ki kell térjek Hídvégi Gáborra.
Ő egy nagyon jó szakember, széles látókörű, sokat tud a webről - valami miatt viszont nem képes elfogadni az objektumorientáltság hasznát. Hozzáteszem: nem is mindig van létjogosultsága, de honlapoknál, webalkalmazásoknál az esetek túlnyomó többségében van.
Szóval ebben az egy dologban ne hallgass Gáborra, sok más dologban viszont tartsd szemed előtt az ő sokszor "árral szembemenő" véleményét, mert ha néha túloz is, szinte mindig van valamennyi igaza.
21

frameworkot és az Angol

Szita Szilárd · 2013. Okt. 12. (Szo), 08.00
Köszi a részletes választ, de soha nem tudtam, hogy mire jó
framework
.
Miért jó, ha valaki ilyet ismer?
Angol, szerinted egy php dokumentum olvasásához és megértéséhez, mekkora angol tudásszükséges?
23

A processzor csak nullákat és

inf · 2013. Okt. 12. (Szo), 08.48
A processzor csak nullákat és egyeseket ismer, ezt alacsony absztrakciós szintű nyelvnek hívják, az emberi nyelv, amivel egy-egy specifikációt megadunk viszont ettől teljesen más, azt magas absztrakciós szintű nyelvnek hívják. A programozó feladata, hogy ezt az absztrakciós szintkülönbséget legyőzze. Ha elkezdesz egy projektet egy magas szintű programozási nyelvben, mint pl java, akkor sokkal kevesebbet fogsz dolgozni vele, mintha egy alacsony szintű nyelvvel csináltad volna, pl assembly, mert kisebb az absztrakciós szintkülönbség, amit le kell győznöd, készen kapsz egy csomó dolgot a nyelvvel. Ugyanez a helyzet egy adott célra használható keretrendszerrel. Valaki más már munkát fektetett bele, így magasabb absztrakciós szintről tudsz indulni, ha ilyet használsz, és ezért gyorsabban tudsz dolzni, mert nem kell mindent az alapoktól megírnod. A magasabb szintű nyelvek, ill. a keretrendszerek használatának az az előnye és hátránya is, hogy - jó esetben - általánosabb, újrahasznosítható kódot tartalmaznak. Ha egy általános kódot futtatsz, akkor annak plusz költsége van ahhoz képest, ha egy specifikusabb kódot futtatsz, így az általános kód futása lassabb lesz. Szóval ha mondjuk ORM-et használsz adatbázissal történő kommunikációhoz, akkor az lassabb lesz, mintha kézzel írnád meg saját magad az SQL-eidet. Szóval összefoglalva, ha a sebesség a fő szempont, akkor alacsony szintű nyelveket érdemes használni, ha a gyors munka, és könnyen kezelhető kód a szempont, akkor magas szintű nyelveket érdemes használni. Valószínűleg mindkét típushoz vannak olyan keretrendszerek, amelyek megkönnyítik a munkát. Általában egy weblapnál vagy webalkalmazásnál nem a sebesség szokott a fő szempont lenni, hanem a könnyű módosíthatóság, így ezeket magas szintű nyelveken írják keretrendszerek használatával, aztán az optimalizáláskor eldől, hogy a kód melyik részein kell más algoritmust, más tervezési megközelítést, stb... használni ahhoz, hogy gyorsabb legyen. Előfordulhat, hogy a kód ezen részeit kevésbé általánosra - alacsonyabb absztrakciós szintűre - kell átírni ahhoz, hogy növekedjen a sebesség.
67

Kicsit egyszerűbben, mint inf3rno... :)

Pepita · 2013. Okt. 13. (V), 23.41
A framework leginkább arra jó, hogy "helyetted dolgozzon". Példáért maradjunk a már említett munkamenetnél. Nem sokkal egyszerűbb, ha a munkameneted "magától" indul, neked pedig mindössze annyi dolgod van, hogy előregyártott, könnyen használható függvényekkel ments vagy kiolvass munkamenetbe mentett adatokat? Pl. így:
$this->session->set_userdata('platform', 'desktop'); // íráshoz
$this->session->userdata('platform'); // Kiolvasáshoz
Dehogynem. Ez persze egy OOP fw, "szokása", hogy ha nem létezik a session-ben a lekérdezett nevű adat, akkor false-al tér vissza (ez jó is meg nem is).
De ez csak egy kényelem a millió közül. Pl. ott az adatbáziskezelés: akár helyetted escape-el, komplett mentést készít - egyszóval számtalan helyen egyetlen sor kódot írsz 10-20 helyett. Ezért jó, ha ilyet ismersz.
Meg kell találd a számodra megfelelőt, szerintem egyben elég ha profi vagy, de ahhoz, hogy a neked jót megtaláld, többet is meg kell nézni.
Elsőnek én bátorkodom javasolni a CodeIgniter-t, vannak ugyan hibái is, de könnyen megismerhető-elsajátítható, és bizony nagy forgalmú oldalaknál is használják helyenként, tehát nagyon rossz nem lehet.
Látható, hogy a manual nem teljes még magyarul, a fw fordításával sem voltam elégedett, de én sem vagyok túl jó angolból, úgyhogy nem vettem részt a fordításokban.
Azt javaslom, hogy csak az angolt töltsd le (manuallal együtt), az alapján csinálj hello wordot, aztán két-három oldalt, amiben már lesz némi generált tartalom. A controlleredet hívd csak Oldal-nak, hogy routing nélkül is szép URL-ed legyen. Ami ebből kínai, olvass utána a manualban (angolul!).
Eleinte egy gyötrődés lesz a sok szótárazás, stb., remélem lesz aki segít benne (az angolban).
Ha így lassan-lassan el tudod kezdeni használni, akkor máris STOP!, tessék utánanézni OOP-nek, MVC-nek rendesen (min. wikipedia), csak utána tovább. Szerintem a CI manualja egész jó. És műxik offline is, csak akkor keresőd nincs.
szerinted egy php dokumentum olvasásához és megértéséhez, mekkora angol tudásszükséges?
Itt egy kicsit a magyarral is baj van... :) Nem tudom mi a php dokumentum, illetve gondolom itt dokumentációra gondolsz. Mekkora? Az elég, ami nekem van. Most jól megmondtam, bocs. Kérdezz meg egy szakmai angoltanárt, szerintem az IT-s (szakmai) alapfokú C megfelel. De doksija is válogatja, van aki irodalmárnak jobb, mint programozónak - ez mondjuk túlzás, de mindent én sem tudok elolvasni, ha olyan szószátyár, mint én magyarul... :)
22

A hetvenes-nyolcvanas évektől

Hidvégi Gábor · 2013. Okt. 12. (Szo), 08.18
A hetvenes-nyolcvanas évektől egészen napjainkig azt sulykolták, hogy ne együnk vajat, ne főzzünk zsírral, mert egészségtelenek, helyette margarint és olajat használjunk. Nemrég fordult a szélirány száznyolcvan fokot, most már lehet ismét zsírban és vajban tocsogni, a margarint és a növényi olajakat száműzték. Ezek után hadd legyenek már az embernek fenntartásai a hasonló, dogmatikus kijelentésekkel kapcsolatban : ) Az pedig természetes, hogy rákérdez valaki a negatívumokra, mert nincs olyan, hogy valamivel mindenki csak nyer.

Én nem mondom senkinek, hogy hallgasson rám, hanem inkább a józan eszére.
24

Nemrég fordult a szélirány

inf · 2013. Okt. 12. (Szo), 08.50
Nemrég fordult a szélirány száznyolcvan fokot, most már lehet ismét zsírban és vajban tocsogni, a margarint és a növényi olajakat száműzték.


Ez szimplán nem igaz, de nagyon off lenne belemenni a dolog részleteibe.

Az pedig természetes, hogy rákérdez valaki a negatívumokra, mert nincs olyan, hogy valamivel mindenki csak nyer.


Persze, mindennek lehetnek negatívumai.
27

Beírtam a keresőbe azt, hogy

Hidvégi Gábor · 2013. Okt. 12. (Szo), 09.29
Beírtam a keresőbe azt, hogy margarin, és ezeket dobta ki, címek és leírások az első oldalról
- A margarin sem a régi - Origo
- A transzzsírsavak túlzott fogyasztásáért a legtöbben a margarint hibáztatják
- erdély ma - A gyilkos margarin
- Egyre több egészséggel foglalkozó fórumon lehet arról olvasni, hogy a szívbarát margarin nem is olyan egészséges, mint ahogy azt a reklámok állítják

A fenti állítást, amit idéztél, pedig olyanoktól hallottam mostanában többször, akik rendszeresen néznek tévét, hallgatnak rádiót és újságokat olvasnak, valamint én is láttam már mindenféle bulvármagazinokban (mint az origó). Persze nem vonom kétségbe az állításod mint biológusé, de a fősodor szerint jelenleg ez a vélemény.
36

"Persze nem vonom kétségbe az

inf · 2013. Okt. 12. (Szo), 12.20
"Persze nem vonom kétségbe az állításod mint biológusé, de a fősodor szerint jelenleg ez a vélemény."

Ez egyáltalán nem igaz, a média sarkít, a bulvár magazinok meg főleg. Ez kb olyan, mintha az origoban írnának valamit a programozásról, és onnantól az lenne a szentírás a szoftverfejlesztésben... A tudományban általában tudományos cikkekre szokás hivatkozni, ilyeneket a scholar.google.com-al találhatsz.

Az omega-3 zsírsavak továbbra is egészségesek, az omega-6 szintén, ha elég omega-3-at fogyasztunk melléjük. A telített zsír egészségtelen, a transz zsír még egészségtelenebb.

A mostani margarinok egy részét már tisztítják transz zsírra (amire rá van írva, hogy szívbarát, meg fel van tüntetve rajta a transz zsír tartalom), így azokban csak minimális mennyiség marad, nem több, mint ami a vajban van. Az ipari zsíroknál, mint amivel a legtöbb olcsó péksütemény, croissant, töltött ostya, stb... készül még mindig magas a transz zsír tartalom, de néhány éven belül elméletileg tilos lesz ilyet forgalmazni. Addig meg itt egy táblázat, ami alapján transz-zsír ügyben lehet dönteni: tfacsop.pdf. Én személy szerint margarin témában azt vallom, hogy felesleges mindenféle zsíros ragacsot rákenni a kenyérre, anélkül is lehet szendvicset csinálni...

Az olajok hevítésénél szintén transz zsírok keletkeznek, pl 1 óra olajban sütésnél 1% alakul át ciszből transzra. Antioxidánsokkal késleltethető valamelyest a dolog, mert akkor először azok égnek el, ezért pl az olivaolaj elég jó ilyen szempontból a magas antioxidáns tartalma miatt. A gyorséttermek általában sűrűn cserélik az olajukat, és speciális olajat, illetve adalékokat használnak, hogy ne legyen magas az ételek transz zsír tartalma. A kínai éttermek gondolom borzasztóak ilyen szempontból, ha csak azt nézzük, hogy a wok-nál a fekete réteg - ami az acélon van - az mind ráégett olaj, ami sütésnél hullik bele a kajába... Salátákba, vagy magában (olajbogyó), vagy főzésnél, vagy rövid ideig tartó sütésnél jó az olaj. Hosszú ideig tartó sütésnél a legjobb nem rátenni semmilyen zsíradékot, a húsokból úgyis ki szokott sülni pont elég... Aki mindenképp rántotthúst, vagy ilyesmit akar enni, az meg cserélje le az olaját minden sütés után, és használjon oliva vagy pl mogyoró olajat. Ezek sokkal drágábbak, mint a napraforgó olaj, de pl palacsinta sütésnél egyáltalán nincs olajszag a konyhában, ha mogyoróolajat használ az ember, mert az nem ég oda úgy, mint pl a napraforgó, és ugyanúgy íztelen.

Még tudnék sokat írni élelmiszeres témáról, de talán ennyi off elég lesz mára...
39

Továbbra sem kételkedek a

Hidvégi Gábor · 2013. Okt. 12. (Szo), 12.51
Továbbra sem kételkedek a szavaidban. De az átlagember mit olvas, origót vagy scholar googlét?
41

"De az átlagember mit olvas,

inf · 2013. Okt. 12. (Szo), 13.05
"De az átlagember mit olvas, origót vagy scholar googlét?"

Nem vágom hogy jön ez ide...
43

»Persze nem vonom kétségbe az

Hidvégi Gábor · 2013. Okt. 12. (Szo), 13.19
»Persze nem vonom kétségbe az állításod mint biológusé, de a fősodor szerint jelenleg ez a vélemény.«

Ez egyáltalán nem igaz, a média sarkít, a bulvár magazinok meg főleg.
44

Még mindig nem értem, arról

inf · 2013. Okt. 12. (Szo), 13.52
Még mindig nem értem, arról vitatkozunk, hogy a margarin egészséges e vagy sem, ennek semmi köze ahhoz, hogy az átlag ember origot olvas, amin elég sűrűn írnak marhaságot tudományos témában.
76

Off

Hidvégi Gábor · 2013. Okt. 15. (K), 09.33
Vaj vagy margarin? Minden igaz, amit a bulvárról írtál, mert megpróbálják kisiklatni a normális vitát.
77

Lol, ezen jót röhögtem :D Én

inf · 2013. Okt. 15. (K), 10.38
Lol, ezen jót röhögtem :D

Én személy szerint egyiket sem ajánlom, ha valaki egész nap a gép előtt ül, akkor nincs szüksége annyi energiára a szervezetének, amit ezek tárolnak. Mindkettő 80% körüli zsírtartalmú, a zsír meg a legtömörebb energiatároló vegyület a biokémiában. Szóval az ilyesmik fogyasztása könnyen vezethet elhízáshoz. A tejszín, tejföl, sajt, zsír, olaj ugyanebbe a kategóriába esik. Ezekkel azért csínyján kell bánni, vagy rendszeresen kell sportolni...
78

Bocs, a linket csak a poén

Hidvégi Gábor · 2013. Okt. 15. (K), 11.00
Bocs, a linket csak a poén kedvéért tettem be, de az írást magát nem olvastam, ami hiba volt. Légyszi töröljétek.
26

A hetvenes-nyolcvanas évektől

BlaZe · 2013. Okt. 12. (Szo), 09.25
A hetvenes-nyolcvanas évektől egészen napjainkig azt sulykolták, hogy ne együnk vajat, ne főzzünk zsírral, mert egészségtelenek, helyette margarint és olajat használjunk. Nemrég fordult a szélirány száznyolcvan fokot, most már lehet ismét zsírban és vajban tocsogni, a margarint és a növényi olajakat száműzték.

Off: Ez azért így ebben a formában természetesen nem igaz. A margarinnal van baj (az előállítása, hogy gyakorlatilag élelmiszeripari melléktermék), de ez nem jelenti azt, hogy a növényi olajok összessége káros lenne.

Ezek után hadd legyenek már az embernek fenntartásai a hasonló, dogmatikus kijelentésekkel kapcsolatban : )

Az hogy OOP-ben érdemes dolgozni, nem dogmatikus kijelentés. Amikor azt mondtam múltkor, hogy a fejlesztés alapvetően nem divatvezérelt, arra gondoltam, hogy hiába akar valakit valamit nyomatni, ha a gyakorlati életben nem válik be. Minden trend mögött piaci érdeket, és valakinek a lobbitevékenységét sejted. Joggal :) Azt kell látni, hogy ez a folyamat mellékszálként kitermel best practice-eket, metodikákat stb. Gondolok itt arra, hogy a fejlesztőcégeken nagy a nyomás hogy gyorsan, karbantartható, minőségi programokat gyártsanak. Szerinted milyen üzleti cél, meg lobbi vinne rá egy egész szakmát arra, hogy butaságot csináljon, mikor elérhető a jobb, és hatékonyabb eszköz? Mint minden tudomány, a fejlesztés is fejlődik. Feltűnnek projectvezetési és szoftverfejlesztési modellek, ezek közül néhány el is tűnik, mert életképtelen, más megmarad. Az OOP már hosszú ideje bizonyítja a létjogosultságát, olyannyira, hogy jelenleg a tény az, hogy az OOP a leghatékonyabb paradigma. Ezt teljesen értelmetlen vitatni.

Az pedig természetes, hogy rákérdez valaki a negatívumokra, mert nincs olyan, hogy valamivel mindenki csak nyer.

Az OOP-nek van overheadje, elsősorban memory footprintben. Egy objektumnak vannak állapotai, és szükséges róla karbantartani néhány metaadatot. Ez értelemszerűen memóriafoglalással jár. Mindezzel együtt ez az alkalmazások sokkal nagyobb százalékában irreleváns, mint azt egyáltalán el tudnád képzelni. Ahol ez az overhead nem fér bele, az a hardware programozás (ott is jellemzően inkább microhardware), valamint az ultra-low latency programozás témaköre. Nagyjából az összes többi területen az OOP hódít. Hogy ezt az egészet tudd hová tenni: pénzügyi cégek sokmillió dollárt fizetnek ki azért, hogy fizikailag közelebb legyenek pl a tőzsde központi szervereihez, mert maga a hálózati forgalom latency-je annyit számít. Ennek ellenére a kereskedési alkalmazások OOP-vel készülnek (nyilván ahol szükséges, ott hívnak natív kódot). Példának érdemes megnézni a ma leggyorsabbnak számító kereskedési platform, az LMAX mérési statisztikáit: egy order lehajtása a beérkezéstől a végrehajtáson át a könyvelésig 4 millisec alatt történik meg. Ez egészen elképesztően kicsi szám! És ezt Javaban írták. Nyilván igényel speciális tudást és egy átlagos OOP programtól eltérő technikákat, viszont nagyon masszívan használja az OOP-t. Szóval nyugodtan kijelenthető, hogy a programozók kb 99.99%-ának az OOP jó választás, mert a teljesítmény és egyéb problémák nem emiatt fognak előjönni.
30

Amikor azt mondtam múltkor,

Hidvégi Gábor · 2013. Okt. 12. (Szo), 10.56
Amikor azt mondtam múltkor, hogy a fejlesztés alapvetően nem divatvezérelt, arra gondoltam, hogy hiába akar valakit valamit nyomatni, ha a gyakorlati életben nem válik be.
Kiváló példa erre a jelenleg blogmarkban lévő Bento, amire írt kommentemet ajánlom a figyelmedbe. A felsorolt keretrendszerek beváltak? Igen, tökéletesen működnek. A bento nevű oldal betöltési ideje 10 másodperc, ezt vesd össze az általad említett 4ms válaszidővel.

Szerinted milyen üzleti cél, meg lobbi vinne rá egy egész szakmát arra, hogy butaságot csináljon, mikor elérhető a jobb, és hatékonyabb eszköz?
A bento nevű oldal működéséhez szükséges scriptek mérete érzésre 5k, de legfeljebb tíz. Mi vitte rá ezeket az embereket, hogy 320k-ban oldják meg ezt a feladatot?

Vesd össze:
Az hogy OOP-ben érdemes dolgozni, nem dogmatikus kijelentés.
Ez volt az első mondatod. És az utolsó kettő:
Az OOP már hosszú ideje bizonyítja a létjogosultságát, olyannyira, hogy jelenleg a tény az, hogy az OOP a leghatékonyabb paradigma. Ezt teljesen értelmetlen vitatni.


Az LMAX-ról én is hallottam már, és nem is vitatom az állításaikat, viszont a példád nem a legjobb: mivel nincs összehasonlítási alapunk (ugyanazon a vason más nyelven megírt rendszer), így nem lehet megítélni, hogy ezért a jó hardver, vagy pedig az OOP felelős (hisz Javaban eleve csak úgy programozhatsz).
33

Kiváló példa erre a jelenleg

BlaZe · 2013. Okt. 12. (Szo), 11.56
Kiváló példa erre a jelenleg blogmarkban lévő Bento, amire írt kommentemet ajánlom a figyelmedbe. A felsorolt keretrendszerek beváltak? Igen, tökéletesen működnek. A bento nevű oldal betöltési ideje 10 másodperc, ezt vesd össze az általad említett 4ms válaszidővel.

Ha leflexeled a kezed, akkor a flexnek nincs létjogosultsága, vagy te használtad rosszul? :)

Az LMAX-ról én is hallottam már, és nem is vitatom az állításaikat, viszont a példád nem a legjobb: mivel nincs összehasonlítási alapunk (ugyanazon a vason más nyelven megírt rendszer), így nem lehet megítélni, hogy ezért a jó hardver, vagy pedig az OOP felelős (hisz Javaban eleve csak úgy programozhatsz).

Ezt nem összehasonlításnak írtam, hanem az "OOP túl nehéz és lassú" buta érv ellen, amit sokan sokszor felhoznak ellene.
46

Ezt nem összehasonlításnak

Joó Ádám · 2013. Okt. 12. (Szo), 20.42
Ezt nem összehasonlításnak írtam, hanem az "OOP túl nehéz és lassú" buta érv ellen, amit sokan sokszor felhoznak ellene.


Ez tökéletesen nyelvfüggő: egy JavaScript nyilván sokkal lassabb, mint egy C; egy C++, ha nem használsz polimorfizmust, akkor az pont C.
38

Az OOP jó, csak több vas kell

inf · 2013. Okt. 12. (Szo), 12.51
Az OOP jó, csak több vas kell neki, mert magasabb absztrakciós szintet képvisel, mint a struktúrált megoldás, az általános dolgok meg erőforrás igényesek. OOP-vel is lehet rossz kódot írni, ami overengineered, túl sok absztrakció van benne, és túl sok erőforrást használ feleslegesen. Minden eszköz használatához tudás kell, ha nincs meg a megfelelő tudás, akkor felesleges az eszközt hibáztatni azért, mert nem tudja használni az ember. Az OOP alkalmazásához rengeteget kell tanulni, ha nem vagy hajlandó ebbe energiát fektetni, akkor természetesen ne használd, mert nem lesz jó, amit vele csinálsz, de ne szidd azért az OOP-t, mert te nem tudsz vele fejleszteni. Én sem szidom a struktúrált programozást azért, mert képtelen vagyok benne dolgozni, nem is célom, mert kényelmetlennek találom.
47

Az OOP jó, csak több vas kell

Joó Ádám · 2013. Okt. 12. (Szo), 20.52
Az OOP jó, csak több vas kell neki, mert magasabb absztrakciós szintet képvisel, mint a struktúrált megoldás, az általános dolgok meg erőforrás igényesek.


Ez így egyszerűen csak nem igaz. Attól, hogy a népszerű objektumorientált nyelvek alá sok vas kell, mert valamiért mindenki szerelmes az interpretált dolgokba és a virtuális gépekbe, nem azt jelenti, hogy az OOP lenne erőforrásigényes. Egy polimorf metódus egyetlen mutató feloldásával növeli a hívási költséget és ennek a mutatónak a méretével a memóriaigényt.

Én sem szidom a struktúrált programozást azért, mert képtelen vagyok benne dolgozni, nem is célom, mert kényelmetlennek találom.


Tegyük már tisztába a fogalmakat, a strukturált programozás az az elágazás, ciklus és függvényhívás. Te is strukturáltan programozol, csak még ezen felül objektumorientáltan is.
34

Az OOP már hosszú ideje

tgr · 2013. Okt. 12. (Szo), 12.03
Az OOP már hosszú ideje bizonyítja a létjogosultságát, olyannyira, hogy jelenleg a tény az, hogy az OOP a leghatékonyabb paradigma.

Ezzel azért a funkcionális programozás hívei vitatkoznának :-) (És akkor ott van még a LISP.) Mondjuk inkább úgy, hogy az OOP-nek a legjobb az ár/érték aránya (ár alatt a megtanulás nehézségét értve).
42

És akkor ott van még a

Hidvégi Gábor · 2013. Okt. 12. (Szo), 13.17
És akkor ott van még a LISP.
Ez egy nagyon jó írás. Vajon a LISP a mai világban is így megállja a helyét?
48

A funkcionális programozás,

Joó Ádám · 2013. Okt. 12. (Szo), 20.58
A funkcionális programozás, már ha szigorú értelemben veszed, tehát nem módosítasz adatot, rendkívül erőforráspazarló a rengeteg másolgatás miatt. Amiért felértékelődik, az az, hogy éppen ezért könnyű benne többszálú programokat írni és elosztani.

Egyébként a funkcionális és objektumorientált programozás ortogonális dolgok, a Common Lispnek például van egy igen fejlett objektumrendszere.
68

Miért kellene bármilyen

tgr · 2013. Okt. 14. (H), 23.31
Miért kellene bármilyen értelemben vett funkcionális programozásnál másolgatni? Pontosan mert nem módosítasz adatot, ha két dolog egyenlő, akkor nincs is szükség két külön reprezentációra (szemben az érték szerinti paraméterátadással dolgozó procedurális programokkal). Az egész program egyetlen kifejezésfa, amit felülről lefelé lazy módon kiértékelsz, mit kell ehhez másolni?
69

Ha módosítasz egy sztringet,

Joó Ádám · 2013. Okt. 15. (K), 00.11
Ha módosítasz egy sztringet, akkor az egészet lemásolod, és azon változtatsz.
70

Azért ez a procedurális

MadBence · 2013. Okt. 15. (K), 00.17
Azért ez a procedurális nyelvek többségében is így van (alapból) :-)
72

Nyelv procedurális?

Pepita · 2013. Okt. 15. (K), 00.21
Mitől procedurális egy nyelv? Annyi erővel simán OO-nak is hívhatom, mert ha eljárásokat tudok írni, akkor interface-t is.
74

Attól, amitől OO egy nyelv.

Joó Ádám · 2013. Okt. 15. (K), 00.39
Attól, amitől OO egy nyelv. Annak szánták, azt támogatja. Nyilván a használt programozási paradigma végső soron a fejlesztőn múlik.
73

Ha neked van statisztikád,

Joó Ádám · 2013. Okt. 15. (K), 00.37
Ha neked van statisztikád, akkor megnézhetjük, de egész biztos vagyok benne, hogy a procedurális nyelvek többségében épphogy nem így van, lévén a sztring általában bájttömb. De nyilván nem kell leragadni a sztringnél, tetszőleges lapos adatstruktúrára igaz.
75

Javaban a String immutable,

MadBence · 2013. Okt. 15. (K), 01.33
Javaban a String immutable, JS-ben, Python-ban, C#-ban, PHP-ban úgyszintén. Copy on Write optimalizációkat lehet, hogy csinálnak, ennyire nem jártam utána, de a karakterláncok nem módosíthatóak helyben.
71

OFF

Pepita · 2013. Okt. 15. (K), 00.18
Kíváncsi lennék, hogy az eddig 70 kommentből mennyi hasznos Szilárd számára. :) Picit mintha elkanyarodtunk volna a kérdésétől, nem? Mondjuk nekem tetszik ez a téma is. :)
80

Ha procedurális kódot írsz

tgr · 2013. Okt. 15. (K), 21.17
Ha procedurális kódot írsz funkcionális nyelven, az biztosan nem lesz hatékony.
32

OFF: egy családtag pont

tgr · 2013. Okt. 12. (Szo), 11.40
OFF: egy családtag pont mostanában jött ezzel a hülyeséggel, még kéznél vannak a linkek, amiket összeszedtem neki:
http://mindentudas.hu/elodasok-cikkek/item/108-infarktus-%C3%A9s-koleszterin.html
http://mindentudas.hu/elodasok-cikkek/item/3113-a-lipidek-szerepe-a-sz%C3%ADv-%C3%A9s-%C3%A9rrendszeri-betegs%C3%A9gek-megel%C5%91z%C3%A9s%C3%A9ben.html
http://www.mdosz.hu/pdf/ud/20115.pdf#page=35

Röviden, a margarin nagyobb arányban tartalmaz telitetlen zsírsavakat, mint a vaj és más állati zsiradékok, és a tipikus étrend szegény ezekben, ezért margarint enni vaj helyett egészségesebb (a telitetlen zsírsavak csökkentik a koleszterinszintet, ami a amik fejlett országokban a leggyakoribb megelőzhető halálnemek közé tartozó szívroham és agyvérzés fő előidézője; ezenfelül bizonyos telítetlen zsírsavak, pl. az omega-3, a vitaminokhoz hasonlóan szükséges, de az emberi szervezet által elő nem állítható vegyületek). A hidrogénezés hatására a telitetlen zsírsavak egy része transzzsírsavvá alakul, ami viszont nagyon egészségtelen, úgyhogy a hidrogénezéssel gyártott margarin rosszabb, mint a vaj; ennek megfelelően ma már nem nagyon kapni ilyet.
35

Hiszek nektek inf3rnoval, nem

Hidvégi Gábor · 2013. Okt. 12. (Szo), 12.07
Hiszek nektek inf3rnoval, nem vagyok a téma szakértője, és annyira nem is érdekel. A példának viszont jó, mert egyre többet hallani a zsírról meg a vajról, de hozhatnám a manapság finomított "jó" és "rossz" koleszterint is (egy évtizede még mindenki rossznak gondolta): változik a világ, sosem jelenthetjük ki valamiről, hogy egyértelműen jó vagy rossz.
40

Itt arról van szó, hogy a

inf · 2013. Okt. 12. (Szo), 13.02
Itt arról van szó, hogy a koleszterin a zsírsavval észtert képez, és egyáltalán nem mindegy, hogy milyen zsírsavval. Ha könnyen oxidálható transz vagy telített zsírsavval, akkor miután kiválik az érfalra oxidálódik, és sokkal nehezebben takarítja le onnan a szervezet. A "jó koleszterin" a HDL-ben van, az egy kis zsírokat, fehérjéket tartalmazó gömb, ami az érfalról letakarított koleszterint viszi vissz a májba, a "rossz koleszterin" az LDL-ben van, ez egy picit nagyobb, de hasonló gömb, ez a zsírokat és a koleszterint osztja szét a sejtek között. Ha több az LDL, mint a HDL koleszterin, akkor az azt jelenti, hogy az emberke annyi vagy olyan zsírt zabál, amit már a szervezete nem tud lekaparni az érfalról, így az ott le fog rakódni, és érelmeszesedése lesz.

Ezt a folyamatot szép lassan derítették ki, gondolom először megnézték, hogy az ateroszklerotikus plakk (érfalra lerakódott cumó az érelmeszesedésnél) mit tartalmaz, aztán rájöttek, hogy koleszterint, és ezért úgy gondolták, hogy a koleszterin a fő oka az érelmeszesedésnek. A média világgá kürtölte, és onnantól a koleszterin lett a fő gonosz, jött az az irányzat, hogy a húsok, tojás egészségtelen. Később kiderült, hogy a telített zsírok könnyebben oxidálódnak, így azok lettek a következő bűnösök jött a vaj, tejszín, sajt, stb... tiltása. Később kiderült, hogy a transz zsírok rosszak, jött a margarinok, olajban sütött élelmiszerek tiltása. Pár éve kiderült, hogy az omega-6, omega-3 arány is számít, de ebből már szerintem nem lesznek képesek cikket írni az origonál, mert akkora a zavar az emberek fejében már így is, hogy képtelenek lennének felfogni az egészet... A gond ott van, hogy már az újságírók sem értik, hogy miről írnak, illetve, hogy antalvali meg hasonlók táplálkozástudósnak képzelik magukat...
87

Plusz adalék:

inf · 2013. Nov. 6. (Sze), 14.40
Plusz adalék: http://www.nature.com/nchembio/journal/v6/n6/fig_tab/nchembio.375_F1.html. Az omega-3 zsírsavnál úgy látszik nem csak az játszik fontos szerepet, hogy a koleszterin-észtere mennyire könnyen oxidálódik, hanem az is, hogy a belőle készülő anyagoknak gyulladáscsökkentő hatása van. Ezért számít az omega-6 és omega-3 zsírsavak aránya az olajoknál.

OFF: Csak ne lenne olyan baszott keserű...
7

olyan kódot létrehozni,

szabo.b.gabor · 2013. Okt. 10. (Cs), 20.18
olyan kódot létrehozni, amivel könnyen lehet követni az ügyfelek folyamatosan változó igényeit..
8

+1

Pepita · 2013. Okt. 10. (Cs), 20.55
Ez nagyon jó. És sikerült? Magát átírja, gondolatátvitel után? :)
9

MI-nek hívják, még

inf · 2013. Okt. 10. (Cs), 21.46
MI-nek hívják, még folyamatban van :D
11

OO, MVC, loose coupling,

szabo.b.gabor · 2013. Okt. 11. (P), 08.25
OO, MVC, loose coupling, stb..

+ farok rossz végén levés esetén hibák felismerése, okulás; jó végén levéskor pozitív visszacsatolás
12

Egy asszociációkat és komplex

tgr · 2013. Okt. 11. (P), 08.36
Egy asszociációkat és komplex lekérdezéseket kezelő Active Record modul írása.
25

nem konkret feladat

blacksonic · 2013. Okt. 12. (Szo), 09.11
rajonni arra hogy nagyobb feladatok kis feladatokra bontasaval es folyamatos refaktoralassal mennyire konnyuve valik egy neheznek tuno feladat is, szinte kipottyan a vegen a megoldas
79

itt tartunk

Szita Szilárd · 2013. Okt. 15. (K), 20.52
Ha itt tartunk akkor segit majd valaki AZ oop megerteni?
holnap irok egy PHP programot es azt at irjuk oop-re?
valaki?
81

OK, ha tudok

Pepita · 2013. Okt. 16. (Sze), 00.02
jönni, segítek. Jó ötletet találtál ki, tetszik.
Ha senkinek sem lesz kedve, és engem sem látsz, küldd el privátban, pár napon belül kirakom - remélem.

De ne nagyon bonyolult feladatot válassz elsőre, jó? Szerintem tedd új témába valami "procedurálisból OOP"-szerű címmel.
83

egy egyszeru

Szita Szilárd · 2013. Okt. 16. (Sze), 06.40
Belépést próbáljunk meg.
84

OK,

Pepita · 2013. Okt. 16. (Sze), 11.33
csinálj neki témát (vagy lehet, hogy még én nem láttam).
85

Kész

Szita Szilárd · 2013. Okt. 16. (Sze), 13.30
Meglesheted :)
86

Dehogy kész :)

Pepita · 2013. Okt. 16. (Sze), 23.46
Meglestem.
82

Csináltam valami hasonlót,

inf · 2013. Okt. 16. (Sze), 00.05
Csináltam valami hasonlót régebben, hátha segít, mondjuk hibák ebben is lehetnek, folyamatosan fejlődik az ember...
http://weblabor.hu/forumok/temak/115535#comment-97249