ugrás a tartalomhoz

PHP5 - különbség abszrakt és interface között

Szekeres Gergő · 2007. Dec. 20. (Cs), 16.15
vki meg tudná mondani, mi a gyakorlati különbésg az absztrakt és az interface osztályok között? ugye absztakt osztályt nem lehet példányosítani, és az utódoszályoknak meg kelle valósítani valamennyi absztrakt metódust.

viszont az interface dokumentációjában is hasonlókat találtam (a példányosítást nem említették, de mivel nem tartalmaznak megvalósítást, így gondolom ez itt sem "játszik"), bár igazából mindkettőről elég rövid leírás található...

előre is köszi!
‹ substr_replace probléma tömb átadás <input type='hidden' ... -al ›
 ■
1

néhány dolog

Sulik Szabolcs · 2007. Dec. 20. (Cs), 16.46
Az absztrakt osztály az osztály egy részét megvalósíthatja, bizonyos funkciók megvalósítását tőled követeli meg (itt fontos, hogy megköveteli, nem csak rád bízza). Az interface-szel felületet határozhatsz meg, amit elvársz az azt megvalósító osztálytól (itt is megköveteled), viszont semmi kódot nem tehetsz bele (hiszen felületről van szó).
Namost, az absztrakt osztály azért nem tudod példányosítani, mert egyes részei még nincsenek kifejtve. Interface esetén semmi sincs kifejtve, mindet neked kell megtenni.

Absztrakt osztályból lehet származtatni más osztályt, míg interfacet az osztály nem örököl, hanem megvalósít. Ezért egy osztály csak egy absztrakt osztályból származhat, viszont több interfacet is megvalósíthat.

Ja és a kettő nem zárja ki egymást.

class MyClass extends MyAbstractClass implements Countable, ArrayAccess {
...
}
2

interface vs absztrakt osztály

gex · 2007. Dec. 20. (Cs), 16.48
az interface-ben nincs kód, az olyan mint egy vázlat. az absztrakt osztályok viszont már tartalmazhatnak kódrészleteket is, mintha kihúznád vastag vonallal a vázlat főbb részeit. vagy kiszíneznéd. :D
ezen kívül egy osztály implementálhat több interface-t is, viszont csak egy osztályt terjeszthet ki.

ezen kívül szerintem is csak egy hajszál választja el a kettőt.

szerk: azt hiszem Szabolcs szebben írta le a lényeget. :)
4

Egy hajszál?

Nagy Gusztáv · 2007. Dec. 20. (Cs), 17.06
Első ránézésre "filozófiai" terület, de szerintem egy hajszálnál sokkal több az eltérés. A nyelvtani hasonlóságok mellett fontos tervezési különbségek vannak.

Az abztrakt osztályt arra használjuk, hogy közös őse legyen a leszármazottainak, tehát ne kelljen minden leszármazottban ugyanazt megcsinálni. A közös részek mennek az absztrakt ősbe, a leszármazottak pedig csak az ettől való eltéréssel foglalkoznak. Így elkerülhető a redundáns kódolás.

Ezzel szemben az interfész egy felületet nyújt. Ráadásul itt nem a hagyományos értelemben vett öröklődés a cél, hanem az, hogy az alkalmazás két pontja egy absztrakt felületen (interfészen) keresztül tudjon egymáshoz kapcsolódni, és ne kelljen ezen kívül semmit se tudni a másikról.

Ha elkalandozol a tervezési minták (design patterns) felé, akkor nagyon szép példákat találhatsz a témában.
6

néha igen

gex · 2007. Dec. 20. (Cs), 18.11
a közös részek ősosztályba kiemelését én is említettem (meg mindenki más is most már), de ha arra nincs szükség, akkor néha el kell gondolkoznom, hogy egy interface vagy egy absztrakt osztály-e a célravezetőbb. soha nem javaztam, ha foglalkoznék vele lehet, hogy nekem is mindig minden érzésre menne.

a tervezési minták jól dolgok (van is egy jó könyvajánló itt), de weben néha kicsit ágyúval verébre hatásuk van. néha fel is bukkan egy-egy a tervezési minták ész nélküli használata miatti teljesítményprobléma, mint fórumtéma. ennek ellenére jópárat magam is használok, sokkal könnyebb fejleszteni, átláthatóbb, stb.
8

nekem is hasonlóak az érzéseim

Szekeres Gergő · 2007. Dec. 20. (Cs), 21.59
a tervezési mintákkal kapcsolatban. Egy hagyományos desktopos alkalmazásban sokkal inkább lehet tervezési mintákat, sőt, alapból objektumokat alkalmazni, mint http protokolon. Persze, XXI. század, de néha kicsit eröltetettnek érzem.
11

design pattern létjogosultsága weben

Hodicska Gergely · 2007. Dec. 22. (Szo), 17.55
Ami írtál, az olyan, mintha az kifejezetten az MVC mintára szűkítetted volna a tervezési mintákat. Arról lehet vitatkozni, hogy kell-e a webre (szerintem igen), de úgy általában a tervezési mintákról szerintem nem, egyértelműen létjogosultságuk van. Ez független nyelvtől, ezek egyszerűen jól kitalált sémák, amik már sokszor bizonyítottak, és ami még nagyon fontos, hogy az őket ismerők számára egy közös nyelv, ha használsz megszokott mintákat, akkor ezzel is érthetőbbé válik a programod.


Üdv,
Felhő
12

MVC?

Szekeres Gergő · 2007. Dec. 23. (V), 16.41
mvcről nem beszéltem, az szerintem pont nem vitatéma...

arra szerettem volna kilyukadni, hogy webes alkalmazások fejlesztése során nagyátlagban pont a tervezési minták használatával válnak túl méretessé a programok. És pont az általad leírtak miatt gondolom ezt: "Ez független nyelvtől, ezek egyszerűen jól kitalált sémák..." nyelvtől független, de azért valljuk be, a webes szerverprogramozás alapszemlélete jelentősen eltér a desktopos esemény-vezérelt programozástól, ahol igazán van létjogosultsága a tervezési mintáknak.

De ez már szerintem nagyon OFF, főleg így karácsony előtt.. :)
13

indoklás?

Hodicska Gergely · 2007. Dec. 24. (H), 13.06
de azért valljuk be, a webes szerverprogramozás alapszemlélete jelentősen eltér a desktopos esemény-vezérelt programozástól,
Na látod, itt megint az eseményvezéreltre teszed a hangsúlyt (ez az MVC része amúgy), de pont az volt a lényege annak amit írtam, hogy a tervezési minták abszolút többsége teljesen független ettől, általános problémákra nyújtanak megoldást.

Szóval nem a szerveroldali prograozás szemlélete a lényeg, hanem a Te szmeléleted, amibe vagy belefér vagy nem a tervezési minták használata.


Üdv,
Felhő
18

kösz hogy felhoztad...

Szekeres Gergő · 2008. Jan. 5. (Szo), 21.46
... ünnepek alatt nem foglalkoztam munkával, így elfejetettem válaszolni. :)

Általános problémára nyújt megoldást persze, de weben azért igen csak más az általános probléma. egy ÁTLAGOS webes projekt során azért annyira sok osztályt nem kell írni, nincsenek annyira bonyolul algoritmusok.

Másrészről mint írtam alapvetően az objektumorientált paradikmákkal vannak "problémáim" webes környezetben. Egy hagyományos alkalmazás során létrehozol egy objektumot, és az a program futásáig él(vagy amíg meg nem szünteted). Nyilván szerveroldali szkript esetén is, de itt a program futása igen csak rövid időd jelent, és az objektumok közi kommunikáció sem olyan hangsúlyos, mert egy kérés során csupán néhány műveletet hajt végre a script. Ebből adódóan úgy érzem, sokszor már-már túl nagy absztrakcióval lehet csak ráhúzni egy feladatra egy-egy tervezési mintát. Amít írtam az - szerintem - az átlagos alkalmazások során van így(egyszerű portálmotor stb.), valószínű Te többször kapsz bonyolultabb feladatokat, ahol lehet tényleg jól jönnek a tervezési minták.
19

minták egy átlagos alkalmazásban

Hodicska Gergely · 2008. Jan. 6. (V), 02.12
Általános problémára nyújt megoldást persze, de weben azért igen csak más az általános probléma. egy ÁTLAGOS webes projekt során azért annyira sok osztályt nem kell írni, nincsenek annyira bonyolul algoritmusok.
Ha egy egyszerűbb portált veszünk, akkor is azért érdemes valamilyen szintű frameworköt használni, és ott már óhatatlanul megjelen(het)nek a tervezési minták. Általában ha van egy frameworköd, és az jól ki van találva, akkor már a konkrét kódokat jóformán beírod a megfelelő helyekre, a legtöbb oldalhoz valszeg tényleg nem lesz szükséged komolyabb dolgokra.

De a framework szintjén igen: singleton, factory, front controller, composite (pl. form és elemei), decorator (pl. page és a layout), observer (pl. loggolás), strategy (ez kb. bárhol előforduhat, ahol valamilyen logikát kiemelsz), proxy (pl. ott van bármilyen webservice-t kezelő cuccban), iterator (pl. egy resultset), adapter (pl. elfeded a phpmailer sajátosságait, hogy bármikor tudd swiftmailerre cserélni).

Ezek szernintem elég alap dolgok bármilyen oldal esetén (portált említettél!). Persze lehet mindent oldalt egyesével leprogramozni, de szerintem az nem egy járható út. És akkor ott van még a DB kérdése, ott is azért könnyen előjöhet valamilyen minta. Pl. egy valamilyen szintű DAO bármilyen egyszerű projekt esetén hasznos tud lenne, szépen elfedi a DB kezelő kódokat a többi résztől, valamint ezeket az amúgy alkalmazásban szétszórva jelentkező kódokat szépen egybe fogja. És ez megint nem csak egy öncélű OOP hülyeség: gyakran látom projektekben, hogy egy DB változtatást tök nehéz végig vezetni a projekten, mert a lekérdezések szét vannak szórva a különböző projektekben, valamint hasonló dolgok le vannak többször programozva, mert nem egy helyen vannak az összetartozó dolgok.

Másrészről mint írtam alapvetően az objektumorientált paradikmákkal vannak "problémáim" webes környezetben.
Ebbe nagyon nem mennék bele (ízlések és pofonok), szerintem az OOP gondolkodás mód, független az adott programozási nyelvtől.


Üdv,
Felhő
14

Igen, csak kérdés, hogy mennyiben tekinthető egy weblap...

Fraki · 2007. Dec. 24. (H), 13.13
Igen, csak kérdés, hogy mennyiben tekinthető egy weblap programnak. Ennek a fényében érdemes nézni a minták kérdéskörét is.
15

Csak amennyire komolyan veszed

vbence · 2007. Dec. 24. (H), 13.46
... a munkádat.
16

mire gondolsz?

Hodicska Gergely · 2007. Dec. 24. (H), 16.12
Mitől nem lenne a weblap mögötti program program?


Üdv,
Felhő
17

Ez a thread belehalt a karácsonyba?

Hodicska Gergely · 2008. Jan. 5. (Szo), 14.55
-
3

nagyon köszi!

Szekeres Gergő · 2007. Dec. 20. (Cs), 17.05
köszi a választ is és a gyors reagálást! már értem:) Amúgy vagy kéne írni weblaborra egy saját php wikit, vagy szólni a srácoknak, hogy dokumentáljanak normálsan, mert az oop része nagyon gyéren van leírva..
5

Dokumentáció

Nagy Gusztáv · 2007. Dec. 20. (Cs), 17.09
Akár te is beszállhatsz a dokumentálásba :-)

Másrészt pedig sokszor látszik, hogy a PHP fejlesztőktől közepes OO alapokat feltételez a dokumentáció, mint ahogy (hozzám hasonlóan) sokan C++ és Java után/mellett PHP-zünk. Egyébként a PHP5 erősen a Java (nagyon szép) logikáját nyúlja le :-)

ui: én szívem szerint Java-s vagyok.
7

ez így van

Szekeres Gergő · 2007. Dec. 20. (Cs), 21.54
pl én is nagyon alap C# után kezdtem php oovel foglalkozni. De nyilván azért minden nyelvben picit mások a lehetőségek, és ezeket szerintem jó lenne kiemelni.

Hogy ellent mondjak magamnak is: mostanában nagyon sok kezdővel találkoztam, akik php-n tanultak programozni, és phpval is tértek rá az oopra. (az egy más kérédés, hogy szerintem ez nagyon nem megfelelő tanulónyelv...).

Ha van lehetőség, örömmel beszállok, de annak nem látom értelmét, hogy mindeki írogasson vmit a saját blogjában. A weblaboron szerintem elég profi tartalmak vannak, és nagyon sokan értenek ehhez, így itt szerintem jól működhetne egy saját wiki.
10

Wiki

presidento · 2007. Dec. 21. (P), 11.20
A weblaboron szerintem elég profi tartalmak vannak, és nagyon sokan értenek ehhez, így itt szerintem jól működhetne egy saját wiki.

Weblabor Wiki (2006.11.22.)
9

láthatóság

pixelsys · 2007. Dec. 21. (P), 09.39
Annyit tennék hozzá, hogy bár látszólag a kettő nagyon hasonló, teljesen más dologra van kitalálva. Az absztrakt osztályban megvan mindhárom láthatósági szint és ennek megfelelően lehet szervezni az osztályt, alapvetően valamilyen taxonómia jellegű konkretizációról van szó (absztrakt osztály madár, leszármazottak veréb, gólya).

Az interfész összes metódusa és attribútuma public, mert ez jellemzően valamilyen tulajdonságot ad hozzá egy meglévő osztályhoz (madár osztály implementálja a repülés interfészt, vagy kicsit webesebb példánál maradva egy listázó objektum megvalósítja (implementálja) a lapózhatóság, felsorolhatóság (iterator) interfészt).

Remélem sikerült még valamit hozzátennem,
Dani