Prototípus objektum-orientált programozás javascript, javascript
Prototype OOP
Az osztályorientált programozás során először egy sablont hozunk létre sablonként, majd létrehozunk egy objektumot. Pontosabb objektumfajták létrehozásához létrehozunk egy osztály leszármazottainak. Vagyis módosítjuk a sablont, és a kapott új sablont használjuk specifikusabb objektumok létrehozására.
A való világban, ha széket akarsz létrehozni, előbb projektet kell létrehoznod papíron, majd a projekt alapján alapozhatsz széket. A projekt itt egy osztály, és a székek tárgyak. Ha hintaszékkel szeretne lenni, akkor átvette volna a projektet, változtatna, és létrehozott egy hintaszéket.
Az Object.create (null) új üres objektumot hoz létre. Ezután új tulajdonságokkal és tulajdonságokkal egészítjük ki az új objektumot:
genericAnimal - objektum, és ennek megfelelően használható:
Most hoztunk létre egy macskát, mint egy normál állat klónja. Hozzáadhatunk tulajdonságokat és funkciókat hozzá:
A macskát prototípusként is használhatjuk, és több macskát is létrehozhatunk:
Az Új kulcsszó és a konstruktor funkció
Mivel ez nem igazán osztály, fontos megérteni, hogy mit csinál a konstruktor hívása. Először egy üres objektum jön létre, akkor ennek az objektumnak a prototípusa a konstruktor prototípus tulajdonságára van beállítva, majd a konstruktorfunkciót ezzel a mutatóval az újonnan létrehozott objektumnak nevezzük, és az objektumot a végén visszaadjuk.
A delegálás és a prototípusok végrehajtása
Az OOP prototípus különbözik a hagyományos OOP-tól, mivel nincs benne osztály - csak olyan tárgyak, amelyek más objektumokból származnak.
Néhány példa az előző kódról illusztrálja ezt a pontot:
A következő sor új üres objektumot hoz létre null __proto__-val:
A következő sor létrehoz egy üres __proto__ objektumot. mutat rágcsálóknak:
Mint látható, minden objektum tartalmaz egy hivatkozást a prototípusára. Tekintsük az Object.create funkciót. Úgy tűnik, hogy a funkció "klónozza" a szülőobjektumot, és a szülő tulajdonságok átmásolódnak a gyermekelemre, de ez nem így van. Amikor capybara jön létre a rágcsálókból. A capybara egy üres tárgy, amely rágcsálóhoz kapcsolódik.
De akkor, ha a létrehozás után kapjuk a capybara.size-t, kapjuk az S mérett, amelyet a szülőobjektumban állítunk be. Milyen varázslat ez? Végül is, a capybara még nem rendelkezik méretű tulajdonsággal. Amikor azonban capybara.size-t írunk. valahogy megkaphatjuk a prototípus méretét.
Az ingatlan beállítása némileg eltérõ. Amikor telepítjük a capybara.size = 'XXL' parancsot. új tulajdonságok mérete. létrejön a capybara objektumban. És legközelebb megpróbáljuk elérni a capybara.size-t. közvetlenül az objektumban találjuk az "XXL" értékkel.
Mivel a prototípus tulajdonság referencia, a prototípus objektumainak módosítása a prototípus használatával minden objektumot érintené. Például, ha rágcsáló és capybara létrehozása után átírjuk a leírás funkciót, vagy hozzáadunk egy új funkciót a genericAnimal-hoz. azonnal elérhetővé válnak a rágcsálókban és capybara-ban való felhasználásra a küldöttségen keresztül.
Objektum.create létrehozása
Objektum létrehozása
Természetesen, ha akarod, írhatsz egy új konstruktort, és beállíthatod a Math-klón prototípusaként. Bontsa ki a kívánt prototípusfunkciókat, majd hozzon létre az objektumot. De miért mennek át mindezek, hogy olyanok legyenek, mint egy osztály, amikor a prototípusok olyan egyszerűek?
Most meg tudjuk felülírni a véletlen funkciót a myMath objektumunkban. Olyan függvényt írtam, amely egész számú véletlen számot ad vissza a felhasználó által meghatározott tartományon belül. Ellenkező esetben véletlenszerű funkció szülőjének hívja:
OOP osztályokon alapul, összehasonlítva az OOP prototípusával
Mindkét megközelítés előnye és hátránya. De a prototípusos OOP könnyebben érthető, rugalmasabb és dinamikusabb.
Ahhoz, hogy megértsük dinamikus természetét, nézzük meg a következő példát: olyan kódot írtunk, amely indexOf függvényt használ a tömbökben. Miután írta és teszteli egy jó böngészőben, vonakodva ellenőrizze az Internet Explorer 8-at. Amint várható, problémák merülnek fel. Mivel az indexOf nincs definiálva az IE8-ban.
Mit csinálsz? Az osztályalapú OOP-ban megoldhatod ezt a problémát úgy, hogy meghatároz egy függvényt egy másik "segítő" osztályban, amely egy Array vagy List bemenetként veszi fel, és felváltja a kódban lévő összes hívást. Vagy a List vagy a ArrayList elemeket alosztályokba rendezheti, egy függvényt definiálhat egy alosztályban, és egy új alosztályt használhat ArrayList helyett.
Olyan osztályok alapján emulálva az OOP-t, amelyek rosszak lehetnek
Vegye figyelembe a következő példát, amelyet pszeudo osztályokkal írtak:
Ez az örökség mintája. Azonban valami vicces történik itt - ha ellenõrzi az ezredestõl.offspring és puff.offspring. akkor vegye észre, hogy mindegyiknek két azonos leszármazottja van!
Mivel úgy néz ki, mintha egy osztályon alapuló egyszerű OOP lenne, ezt a függvényt egy öröklési hierarchia létrehozására használhatjuk, amint az a következő példában látható:
Mindez jól néz ki, amíg úgy gondolja, hogy az OOP osztály. De ha megpróbálod a table.events ['click.expand'] parancsot a konzolban, látni fogod a "bõvítés" -t! Akárhogyan is, a HideableTableView kiterjesztett eseménykezelővel rendelkezik. bár nem volt meghatározva ebben az osztályban.
Itt láthatja ezt a problémát.
A fenti probléma az előző példában leírt okból következett be. A Backbone.js-ben meg kell dolgoznod, próbáld meg úgy nézegetni az osztályokat, hogy lásson egy prototípus láncot a háttérben rejtve. Miután megértette, hogyan épül fel a prototípus lánc, egyszerű megoldást talál erre a problémára.