Statikus az osztályon
„Class-orientáló programozás” - ez az, amikor használni egy osztály, amely csak a statikus módszerek és tulajdonságok, és például az osztály soha létre. Ebben a cikkben fogok beszélni, hogy:
- nem ad semmilyen előnyt procedurális
- ne hagyjon tárgyakat
- statikus osztály tagjait! = halál tesztek
attól függően, hogy
Jellemzően a kód függ más kódot. Például:
Ez a kód függ a változó $ bár és substr függvény. $ Bár - ez csak egy helyi változó határozza némileg meghaladja az azonos fájlt ugyanabban a hatálya alá. substr - függvénye a PHP mag. minden csak itt.
Most, egy példa:
normalizer_normalize - ez a csomag a funkciót Intl, ami be van építve a PHP verzió óta 5.3 és lehet telepíteni külön régebbi verziók. Itt egy kicsit bonyolultabb - műveleti kód függ a rendelkezésre álló egy adott csomagot.
Most egy ilyen opció:
Ez egy tipikus példája egy osztály-orientált programozás. Foo mereven kötődik az adatbázisban. És azt feltételezzük, hogy az osztály Adatbázis már elkészült, az az adatbázis kapcsolat (DB) már telepítve van. Feltételezhető, hogy az ezzel a kód:
Foo :: bár hallgatólagosan függ a rendelkezésre álló adatbázis és a belső állapotát. Nem tudja használni a Foo nélkül Database. és adatbázis. feltehetően igényel adatbázis kapcsolatot. Mivel biztos lehet benne, hogy az adatbázis kapcsolat már létrejött, ha van egy hívás Adatbázis :: fetchAll. Ennek egyik módja a következő:
Amikor hívja Adatbázis :: fetchAll. Megvizsgáljuk, hogy létezik egy kapcsolat hívja a connect módszer. amely szükség esetén megkapja a csatlakozási paramétereket a config. Ez azt jelenti, hogy az adatbázis függ config / database.php fájlt. Ha ez a fájl nem - ez nem működik. Megy tovább. Class Adatbázis kötve egy egységes adatbázis. Ha át kell más kapcsolat paramétereit, akkor, legalábbis nem könnyen. Com növekszik. Foo nemcsak függ a rendelkezésre álló adatbázis. hanem attól függ, hogy annak állapotát. Adatbázis függ az adott fájl egy adott mappában. Ie hallgatólagosan class Foo függ fájlt a mappába, de a kód nem látható. Sőt, van egy csomó függőségek globális körülmények között. Minden darab függ egy másik darabot, ami kell a megfelelő állapotban van, és sehol nem válik ez egyértelműen indokolt.
Valami ismerős.
Nem úgy, mint a procedurális megközelítés? Próbáljuk átírni ezt például az eljárási stílus:
Keresse meg a 10 különbség ...
Tipp: Az egyetlen különbség - a megjelenése Adatbázis :: $ kapcsolat és a $ database_connection.
Az osztály-orientált például a kapcsolat csak a nagyon osztály adatbázis. és eljárási szabályzat, ez a változó globális. A kód ugyanaz függőség, kommunikációs problémák, és ugyanígy működik. Között $ database_connection és Adatbázis :: $ kapcsolat szinte nincs különbség - ez csak egy másik szintaxis ugyanaz, a két változó van a globális állam. Egyszerű névtér plakk használata révén osztályok - ez minden bizonnyal jobb, mint a semmi, de semmi komoly változásokat.
Osztály-orientált programozás - ez olyan, mint vásárol egy autót, hogy üljön benne, rendszeresen nyílt és csukja be az ajtót, ugorj az ülések, véletlenül se okozzanak a tűz a légzsák, de soha nem kapcsoljuk be a gyújtást, és nem mozdult. Ez egy teljes félreértés a lényeg.
Fordítsa az indítókulcsot
Most próbáljuk a PFSZ. Kezdjük végrehajtását Foo:
Most Foo nem függ egy adott adatbázishoz. Amikor létrehoz egy példánya Foo. át kell adni egy objektumot, amely olyan jellemzői Adatbázis. Ez lehet egy példányát az adatbázis. és az ő leszármazottja. Így tudjuk használni a különböző végrehajtási az adatbázisban. amely képes adatokat fogadni bármely más helyen. Vagy egy caching réteg. Vagy egy dugó a vizsgálatok helyett a jelen találmány szerinti vegyület az adatbázis. Most kell, hogy hozzon létre egy adatbázis példány. Ez azt jelenti, hogy több különböző kapcsolatokat különböző adatbázisok különböző paraméterekkel. Nézzük végre Adatbázis:
Figyeljük meg, hogy mennyivel könnyebb megvalósítása volt. Az adatbázis :: fetchAll nem kell, hogy ellenőrizze a kapcsolat állapotát. Hívni Adatbázis :: fetchAll. akkor létre kell hozni egy példányát. Ahhoz, hogy hozzon létre egy példányát az osztálynak, meg kell, hogy adja át a kapcsolat paramétereit a kivitelező. Ha a csatlakozási beállítások érvényesek-e vagy sem a kapcsolat nem hozható létre, mivel egyéb okok miatt, hogy el kell dobni kivétel objektum jön létre. Mindez azt jelenti, hogy ha hívja Adatbázis :: fetchAll. van egy garantált kapcsolat az adatbázissal. Ez azt jelenti, hogy meg kell csak azokat a Foo kivitelező, hogy szüksége van egy Database $ adatbázist, és ez lesz csatlakozni az adatbázishoz.
Anélkül egy példányát Foo. Nem hívhatjuk Foo :: bar. Anélkül, például adatbázis. Nem lehet egy példányának létrehozásához Foo. Érvényes kapcsolat híján a beállításokat, nem hoz létre egy példánya az Adatbázis.
Egyszerűen nem tudja használni a kódot, ha legalább az egyik feltétel nem teljesül.
Hasonlítsuk össze ezt az osztály-orientált kód: hívja Foo :: bárban bármikor, de nem sikerül, akkor az adatbázis-osztály még nem áll készen. Adatbázis :: fetchAll okozhat bármikor, de egy hiba akkor történik, ha problémák vannak a config / database.php fájlt. Adatbázis :: csatlakozni határozat általános állapot, amely meghatározza az összes többi művelet, de ez a függés nem garantálható.
Nézzük meg azt a kódot, amely Foo. Eljárási példa:
Írja ezt a sort bárhol lehet, és ez lesz végrehajtva. A viselkedése függ a globális állam az adatbázis-kapcsolat. Bár ez nem derül ki a kódot. Add hibakezelés:
Mivel az implicit függőségek foo_bar. hiba esetén nehéz lesz megérteni, hogy mit rontottam el.
Összehasonlításképpen itt class-orientált megvalósítás:
Nincs különbség. Hibakezelés - azonos, azaz minden olyan nehéz megtalálni a probléma forrása. Ez azért van, mert hív a statikus módszer - ez csak egy függvényhívás, ami nem különbözik bármely más függvényhívás.
PHP fog esni egy végzetes hibát, amikor az új Foo. Azt hangsúlyozta, hogy a Foo szüksége van egy másolatra adatbázis. de nem felelt meg.
PHP fog esni újra, mert nem egy paramétert az adatbázis-kapcsolat, amit jelzett az Adatbázis :: __ konstrukciót.
Most már elégedett a függőségek, amelyeket ígért, akkor készen áll a haladásra.
De tegyük fel, hogy az adatbázis-kapcsolat beállításait hibás vagy van néhány probléma az adatbázis és a kapcsolat nem hozható létre. Ebben az esetben kivételt fog dobni, amikor az új adatbázis (.). A következő sorok csak nem teljesülnek. Tehát nem kell ellenőrizni a hiba után a hívás $ foo-> bar () (persze, akkor ellenőrizze, hogy vissza). Ha valami elromlik valamelyik függőség, a kód nem kerül végrehajtásra. A dobott kivételt tartalmaz hasznos hibakeresési információkat.
Objektum-orientált megközelítési tűnhet nehezebb. Példánkban eljárási vagy osztály-orientált kód csak egy sort, ami foo_bar vagy Foo :: bar. míg az objektum-orientált; a megközelítés, három sorban. Fontos, hogy elfog a lényegét. Mi nem adja meg az adatbázis eljárási szabályzat, de meg kell csinálni egyébként. A procedurális megközelítést igényel hibakezelés az esemény után, és minden ponton a folyamat. Hiba kezelése nagyon bonyolult, mert nehéz nyomon követni, amelyek implicit függőségek okozta a hibát. Égetve titkos függőség. Nem nyilvánvaló hibaforrás. Ez nem egyértelmű, hogy mi ez függ a kódot a normál működését.
Objektum-orientált; megközelítés teszi minden függőség egyértelmű és nyilvánvaló. A Foo szüksége Database példányt. és a példányt az adatbázis kapcsolat paraméterek szükségesek.
A procedurális megközelítést, a felelősség a funkciót. Felhívjuk a módszer Foo :: bar - most akkor vissza kell adnia az eredmény van szükségünk. Ez a módszer viszont feladatokkal megbízott Adatbázis :: fetchAll. Most a felelősséget, és ő próbál csatlakozni az adatbázishoz, és vissza semmilyen adatot. És ha valami elromlik bármely pontján ... ki tudja, mi jön vissza hozzád, és hol.
Objektum-orientált megközelítés eltolja a felelősséget, hogy a hívó kód, és ez az ő erejét. Hívni kívánt Foo :: bar. Nos, akkor hadd csatlakozni az adatbázishoz. Mi a kapcsolat? Nem számít, mindaddig, amíg ez egy másolatot az adatbázis. Ez a hatalom függőség injekció. Ez egyértelművé teszi a szükséges függőségeket.
Az eljárási szabályzat, akkor hozzon létre egy csomó kemény függőségek és összekeveri acélhuzal különböző részein a kódot. Minden attól függ, mindent. Létrehoz egy monolitikus szoftvert. Nem jelenti azt, hogy nem fog működni. Azt akarom mondani, hogy ez egy nagyon merev szerkezet, ami nagyon nehéz kivenni. Ez jól működik a kis alkalmazás. A nagyméretű kiderül bonyolult a horror, hogy lehetetlen, hogy teszteljék, javítása és hibakeresés:
Az objektum-orientált, bevezetésével a kód függőségek, akkor hozzon létre egy csomó kis blokkok, amelyek mindegyike független. Minden egységnek van egy jól definiált felület, amely használhatja a többi blokk. Minden egység tudja, mit kell másoktól, hogy minden működik. Eljárásjogilag, és az osztály-orientált kódot társítani Foo Adatbázis írása közben kódot. Az objektum-orientált, akkor adja meg a kódot, hogy a Foo kell semmilyen adatbázis. de hagyjuk mozgástér, mivel lehet. Ha a használni kívánt Foo. Meg kell kapcsolódniuk egy meghatározott esetet a Foo egy adott példánya az Adatbázis:
Osztály-orientált megközelítés látszólag egyszerű, de határozottan szögezték körmök kód függőségeket. Az objektum-orientált megközelítés hagy minden rugalmasságot és izolációs használat előtt, ami tűnhet bonyolultabb, de sokkal kezelhetőbb.
statikus tagok
Miért van szükség a statikus tulajdonságok és módszerek? Hasznosak a statikus adatokat. Például az adatokat, amelyekre a példány, de ez soha nem változik. Teljesen elméleti példa:
Képzeljük el, hogy ez az osztály kell kötődni adattípusok az adatbázisból a belső típusokat. Ez megköveteli a kártyák. Ez a kártya ugyanaz minden esetben az adatbázis, és használják a több módszer Database. Miért nem tesz a térkép egy statikus tulajdonság? Ezek soha nem változik, de csak olvasni. És ez fogja megmenteni egy kis memóriát, mert adatok minden példányára az adatbázisban. mert adatokhoz történő hozzáférés csak az osztályon belül, akkor nem hoz létre semmilyen külső függőségek. Statikus tulajdonságok soha nem lehet kívülről hozzáférhető, mert ez csak a globális változók. És láttuk, hogy mi vezet ...
Statikus tulajdonságok is hasznos lehet, tárolt változat néhány adat, amely azonos minden esetben. Statikus tulajdonságok léteznek, a legtöbb, mint egy optimalizálási technikát, azokat nem kell figyelembe venni, mint egy programozási filozófiát. A statikus eljárások alkalmasak, mint kisegítő és alternatív módszerek tervezők.
A probléma a statikus módszerekkel szemben, hogy hozzon létre egy kemény függőség. Ha telefonál Foo :: bar (). ezt a kódsort lesz társítva van egy adott osztály Foo. Ez problémákhoz vezethet.
Statikus engedélyezett módszereket az alábbi körülmények között:
- A függőség garantált ott. Ha a hívás belső vagy függőség része a környezetet. Például:
Ott Adatbázis függ az osztály - OEM. De OEM - része a platform, ez egy osztály dolgozó adatbázisok PHP által. Mindenesetre, hogy működjön együtt az adatbázis kell használni valamilyen API.
Ez a kis segítő funkció wrapper egy speciális algoritmust, amely segít kiszámítani a számos jó érv van $ k. használják a kivitelező. mert meg kell nevezni, mielőtt az osztály példányai, meg kell statikus. Ez az algoritmus nem rendelkezik külső függőségek és nem valószínű, hogy ki kell cserélni. Ezt használják a következők szerint:
Ez nem hoz létre semmilyen további függőségeket. Az osztály függ is.
Mindkét esetben az eredmény egy DateTime fokon, és mindkét esetben, a kód van csatlakoztatva egy osztály DateTime egyébként. Statikus módszer DateTime :: createFromFormat - ish természet egy alternatív tárgy, ami visszaadja a ugyanaz, mint az új DateTime. de a további szolgáltatásokat. Hol lehet írni egy új osztály. írhatunk és Class :: módszer (). Nincs új függőségek, ha ez nem történik meg.
További változatok statikus módszerek befolyásolja a kötődés és alkothatnak implicit függőségeket.
Szó absztrakciós
Miért e nagy felhajtás a függőségek? Lehetőség elvont! A növekedés a terméket, növelve annak összetettségét. És egy absztrakció - a legfontosabb, hogy a komplexitás kezelése.
Például, ha az osztály Application. amely képviseli az alkalmazás. Kommunikál a felhasználói osztály. amely tagja a bemutatott. Amely megkapja az adatokat az adatbázisból. Class Adatbázis szüksége DatabaseDriver. DatabaseDriver szükséges kapcsolati beállításokat. És így tovább. Ha csak hívja Application :: start () statikus, amelynek hatására a Felhasználó :: getData () statikus, amelynek hatására egy statikus adatbázis, és így tovább, abban a reményben, hogy minden réteget fog foglalkozni a függőségek, akkor kap egy szörnyű rendetlenség, ha valami nem megy rossz. Lehetetlen kitalálni, hogy hogy működik a hívás Application :: Start (). mert nem egyértelmű, hogyan kell viselkedniük szerint a belső. Még rosszabb, hogy az egyetlen módja annak, hogy befolyásolja a viselkedését a bejelentés :: start () -, hogy módosítsa a forráskódot ezen osztály és az osztály kódját, hogy ő vyzyzvaet osztályok és kódot vyzyzvayut ezeket az osztályokat ... a házban, hogy Jack épült.
A leghatékonyabb megközelítés az összetett alkalmazások - a létrehozása az egyes részek, amelyek akkor számíthat a jövőben. Részei, amelyek másra gondolni, biztos lehet benne. Például, ha hívja a statikus Adatbázis :: fetchAll (.). nincs garancia arra, hogy a kapcsolatot az adatbázis már telepített vagy telepítésre kerül.
Ha a kód belsejében ez a funkció kerül sor - ez azt jelenti, hogy a példány az adatbázis sikeresen továbbított, ami azt jelenti, hogy a példány az adatbázis-objektum létrehozása sikeresen megtörtént. Ha az adatbázis osztály célja van, akkor biztos lehet benne, hogy a jelenléte egy példánya ennek az osztálynak az a képesség, amellyel adatbázis lekérdezések. Ha nincs esetben az osztály, a test a funkció nem kerül végrehajtásra. Ez azt jelenti, hogy a funkció nem kell aggódnia az állam az adatbázis, a Database osztály csinálni magamnak. Ez a megközelítés megszünteti a függőségek és összpontosítani problémák megoldásához.
Anélkül, hogy a képesség, hogy gondolni függőségek és függőségek ilyen függőség, ez gyakorlatilag lehetetlen, hogy írjon, bár egy kicsit bonyolult alkalmazás. Adatbázis lehet egy kis wrapper class vagy hatalmas többrétegű szörnyeteg sok függőségek, akkor indul, mint egy kis boríték és változékonysága, ha ez a hatalmas szörny a korral, akkor örököl egy osztály adatbázis, és adja át a funkciót leszármazottja, ez nem fontos, hogy a funkció (Database $ adatbázis). -ig, adatbázis nyilvános felületen nem változik. Ha az osztályok jól elkülönül a többi alkalmazást függőség injekció, tesztelheti mindegyiket a csonk helyett függőségek. Amikor tesztelték az osztály elég, hogy megbizonyosodjon arról, hogy működik, ahogy kellene, akkor dobja ki a felesleges ki a fejét, csak tudni, hogy mit kell dolgozni az adatbázist kell használni Database példányt.
Osztály-orientált programozás - butaság. Tanuld meg használni OOP.