ugrás a tartalomhoz

Abstraction()->_Abstraction()->__Abstraction()

Hidvégi Gábor · 2014. Ápr. 9. (Sze), 10.37
Mikor érdemes absztrakciót bevezetni?
 ■
1

Túltervezés

vbence · 2014. Ápr. 11. (P), 16.55
Mint mindent, ezt is túlzásba lehet vinni. A szakmát elnézve egyelőre úgy látom túl keveset vannak használva a tervezési minták, a túltervezés szörnyetegével való riogatást elég korainak érzem.
2

Relatív

Hidvégi Gábor · 2014. Ápr. 12. (Szo), 14.57
Látod, ez szubjektív, mert az alapján, amit én látok, túl sok az absztrakció. Az igazság valószínűleg valahol a kettő között lehet.
3

Pontosan

Pepita · 2014. Ápr. 14. (H), 20.17
Valahol a kettő között - mindkét szélsőségre vannak fejlesztői példák.
4

Aktivitás

vbence · 2014. Ápr. 16. (Sze), 09.26
Én elsősorban abból indultam ki, hogy itt, a Weblaboron naponta látok SQL, esetleg PHP API kérdéseket, de olyat így hirtelen nem tudok felidézni (a közelmúltból biztosan nem), amikor egy szolgáltatás APIjának megtervezéséhez vagy egy feladathoz választandó mintákkal kapcsolatban kért volna valaki segítséget (esetleg két konkurens megoldás előnyeit/hátrányait latolgatta).

Persze lehet hogy mindenki ezt intuitívan tudja és nem kell kérdeznie. Az is lehet hogy a többség leszarja. (Én feltételeztem a másodikat ;)
5

1nf3rn0-nak szoktak ilyen

Hidvégi Gábor · 2014. Ápr. 16. (Sze), 09.54
1nf3rn0-nak szoktak ilyen jellegű kérdései lenni.
6

Én se nagyon találkozom olyan

bamegakapa · 2014. Ápr. 16. (Sze), 11.50
Én se nagyon találkozom olyan kóddal, ahol túlzásba vitték volna a dolgot. Ha mégis, már az is értékelendő, hiszen legalább az igyekezet megvolt, a tanulás és jobb szakemberré válás iránti vágy, és nem a teljes ignorancia, a jóóleszaz hozzáállás manifesztálódása egy nagy tál spagettikódban. Rosszabb esetben ideológiával alátámasztva :).
7

Tehát akinek a kódjában nincs

Hidvégi Gábor · 2014. Ápr. 16. (Sze), 13.45
Tehát akinek a kódjában nincs túlzásba víve az absztrakciók halmozása, az ignoráns, spagettikódot író, ideologizáló patópál? Az is az, aki megvárja, hogy mivé forrja ki magát egy technika, és igyekszik más tapasztalataiból okulni?
8

Ha ezt olvasod ki abból, amit

bamegakapa · 2014. Ápr. 16. (Sze), 13.54
Ha ezt olvasod ki abból, amit írtam...

Ezen kiforratlan technikák egy része tudtommal több évtizedes, más részüket évek óta sikerrel használják. Biztos találsz majd kettőt-hármat, amire ez nem igaz, kíméld meg magad attól, hogy begépeled őket :).
9

Ki mondta, hogy vannak több

Hidvégi Gábor · 2014. Ápr. 16. (Sze), 15.02
Ki mondta, hogy vannak több évtizedes kiforratlan technikák? Pontosan mik azok?
10

Amik ellen általában

bamegakapa · 2014. Ápr. 16. (Sze), 16.32
Amik ellen általában keresztesháborút vívsz. Nem hiszem, hogy a tervezési minták, az OOP vagy akár a tesztek írása egy pár hónapos, éppen hirtelen felkapott és hájpolt, múló hóbort lenne. Persze nem vagyok nagy szakértő a témában.
11

Sosem állítottam, hogy ezek

Hidvégi Gábor · 2014. Ápr. 16. (Sze), 17.45
Sosem állítottam, hogy ezek kiforratlan technikák, és nem ellenük küzdök, hanem az indokolatlan használatuk ellen.
12

Komolyan elgondolkodtam, de

BlaZe · 2014. Ápr. 16. (Sze), 20.49
Komolyan elgondolkodtam, de én ilyennel nem igazán találkoztam még a munkám során... Olyannal viszont elég sokkal, ahol szenvedtek a rossz minőségű, merev, vagy teszt nélküli megoldásoktól. Elég nagy cégnél is láttam projecte(ke)t (többek között) emiatt teljesen megcsúszni, állandó bugfixálásba torkollni, majd leépülni.
13

A tesztekkel kapcsolatban

Hidvégi Gábor · 2014. Ápr. 16. (Sze), 21.35
A tesztekkel kapcsolatban egyelőre semleges állásponton vagyok, látom az előnyeiket és hátrányaikat; jelen pillanatban úgy gondolom, hogy nélkülük is lehet stabil programot írni, legalábbis az eddigi tapasztalataim ezt mutatják.

A tervezési mintákról azt gondolom, hogy ha az ember jól dolgozik, a programban automatikusan "ki fognak rajzolódni" a fejlesztés során (ez a blogmark is erről szól).

Az OOP-ről továbbra is lesúlytó a véleményem, egy nagyon ingatag lábakon álló paradigma, amiről, ha megkérdezünk két kollegát, mindketten mást és mást mondanak. Az öröklődés és a polimorfizmus egy merev, csak vertikálisan bővíthető struktúrát hoz létre, az adatok és a hozzájuk tartozó függvények "coupled" kódot eredményeznek, amitől máshol mindenáron meg akarnak szabadulni a szakemberek, és ha ezek után megnézzük, mi is marad az OOP-ből, hát, nem túl sok minden.

És ennek ellenére elismerem, hogy mégiscsak lehet jó programot OOP alapokon fejleszteni, ilyenekkel dolgozom nap mint nap, mert valaki ezzel a módszerrel is tud jó munkát kiadni a kezéből, másnak meg más elképzelések jobban fekszenek. Nem vagyunk egyformák.
14

Nem akarok megint belemenni,

BlaZe · 2014. Ápr. 16. (Sze), 22.06
Nem akarok megint belemenni, de szerintem olvass el pár alap könyvet a témában. Clean code, GOF pl. Konzekvensen és tényszerűen nem igaz, amit írsz az OOP-ről (pl hogy csak vertikálisan bővíthető, meg hogy coupled), a többi meg már többszörösen ki lett tárgyalva. Ami nem nekem baj, csak eléggé meglepő, hogy láthatóan sokat olvasol mindenféle témában és nagyon komoly energiát fektetsz abba, hogy harcolj valami ellen, amit viszont nem vagy hajlandó olyan mélységben megismerni, hogy valójában tudj róla vitatkozni. Ez így csak arra jó, hogy ha olyan olvassa aki esetleg csak ismerkedik a témával, azt teljesen összezavard.
15

Olvasok tovább. Hátha egyszer

Hidvégi Gábor · 2014. Ápr. 17. (Cs), 07.54
Olvasok tovább. Hátha egyszer megvilágosodom : )

Fontos: nem azt írtam, hogy az OOP per se vertikálisan bővíthető kódot eredményez, hanem azt, hogy ez akkor áll fenn, ha polimorfizmust használunk. Lényeges különbség.

az adatok és a hozzájuk tartozó függvények "coupled" kódot eredményeznek
Idézet a wikipédiából:
... encapsulation is ... A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data
16

Encapsulation

vbence · 2014. Ápr. 17. (Cs), 12.37
Az encapsulationt magyarul "egységbe zárásnak" szokás fordítani, (vagyis hogy egy objektum annyival több egy rekordnál, hogy nem csak az összetartozó adatstruktúrát, de a hozzájuk - szorosan - kapcsolódó kódot is tartalmazza).

A strong coupling vs. loose coupling témaköre - legjobb tudásom szerint - inkább arról szól, hogy interfésztől függjünk és ne implementációtól (így az adott implementáció később cserélhető anélkül, hogy a tőle függő kódon változtathatnánk).
17

Kérdések

Hidvégi Gábor · 2014. Ápr. 17. (Cs), 13.01
Miért korlátozunk le bárkit, hogy az adott adatstruktúrán csak a mi függvényeinkkel lehet műveleteket végezni? Miért korlátozunk le bárkit, hogy az adott függvényekkel csak a mi adatstruktúránkon végezhetünk műveleteket?
18

API tervezés

vbence · 2014. Ápr. 17. (Cs), 13.29
Ez már a saját API tervezéseden múlik (vagyis lehet gettered/settered minden adathoz). A lényeg, hogy megteheted.. ;)

Az alap elgondolás, hogy az implementációt (egy függvény tartalmát) később változtathasd. Ha publikus adattagjaid vannak, azoknak a működését nem tudod lecserélni, csak a függvényekért. - Egyes nyelvekben léteznek propertyk, amik kívülről adattagoknak látszanak, belülről viszont valójában függvények (aminek tartalma módosítható).

Tipikus példám szokott lenni:
class Előadás {
    public kezdetiIdő;
    public hossz;
}
Most tételezzük fel, hogy megváltozik az adatszerkezet:
class Előadás {
    public kezdetiIdő;
    public befejezésiIdő;
}
A kód, ami eddig dolgozott az objektumunkkal már működésképtelen. Ezzel szemben a következő objektum:
class Előadás {
    private kezdetiIdő;
    private hossz;

    public getKezdésiIdő() { return kezdésiIdő; }
    public getHossz() { return hossz; }
}
könnyen módosítható:
class Előadás {
    private kezdetiIdő;
    private befejezésiIdő;

    public getKezdésiIdő() { return kezdésiIdő; }
    public getBefejezésiIdő() { return befejezésiIdő; }
    public getHossz() { return befejezésiIdő - kezdésiIdő; }
}
... és így az interfész nem törik el.

A struktúra (private láthatóság) garantálja, hogy az adatokra csak ebben a fájlban (azon belül ebben a classban) hívatkozol. Tehát ahelyett, hogy az egész programodat át kéne fésülni megváltoztatandó kódért, itt tudod hogy ha a classod lefordul akkor máshol már tuti nem lesz gond.
19

Szétbontás

Hidvégi Gábor · 2014. Ápr. 17. (Cs), 13.44
Lehet, hogy én értek félre valamit, de nekem a fentiek ellenkeznek azzal, amit tgr írt múltkor:
Ettől teljesen eltérő kérdés, hogy van-e állapota egy függvénynek/objektumnak. Általában igaz, hogy minél kevesebbnek van, annál jobb (könnyebb érvelni a kód helyességéről), OOP-ben ezt tipikusan úgy oldod meg, hogy szétbontod a kódot value objectekre, amikben csak állapot van, logika nincs, és service-ekre, amikben csak logika van, állapot nincs.
21

Tanácsok

vbence · 2014. Ápr. 17. (Cs), 22.39
Az idézett tanácsok jó megközelítést képviselnek egy adatvezérelt (web)alkalmazás üzleti logikájának implementálásánál. A fenti példa osztálya nagyon hasonlít egy tipikus value objectre. Arról hogy ott megengedhető-e ilyen szintű logika implementálása eltérő vélemények léteznek (néha praktikus, néha kevésbé).

Az alkalmazást fenntartó infrastruktúra (pl. az ORM) nagyságrendekkel bonyolultabb problémákat old meg, mint amik az alkalmazás logikáját képezik. A tgr által írt ökölszabály tipikusan az adatközpontú műveletekre vonatkozik. Az OOP irányelvei általánosabb érvényűek.
20

Fontos: nem azt írtam, hogy

BlaZe · 2014. Ápr. 17. (Cs), 21.31
Fontos: nem azt írtam, hogy az OOP per se vertikálisan bővíthető kódot eredményez, hanem azt, hogy ez akkor áll fenn, ha polimorfizmust használunk. Lényeges különbség.
Nem értem ezt az állítást. Mit jelent az, hogy csak vertikálisan bővíthető, ha polimorfizmust használunk? Polimorfizmus != öröklődés. Az öröklés+override egy módja a polimorfizmus elérésének. Egy másik az implementálás. És végülis a kompozíció is egyfajta polimorfizmus.

Az encapsulation vs coupled dolgot sem értem. A kód mindig coupled a használt változókhoz, ha ragaszkodsz hozzá, hogy ebben az amúgy nem használt kontextusban használjuk ezt a jelzőt. A coupled azt jelenti, amit vbence is írt.
22

Öröklődés

Hidvégi Gábor · 2014. Ápr. 19. (Szo), 09.32
Igazad van, nem polimorfizmust kellett volna írnom, hanem öröklődést (+ override). A kompozíció ennél ezerszer rugalmasabb megoldás.