|
|
Közzétéve 2018. 07. 30. 10:30:45
|
|
|
Bevezetés
A flyweight mód hatékonyan támogatja a nagy számú finomszemcsés objektumot azáltal, hogy megosztó technológiát futtat, elkerülve a sok azonos tartalommal rendelkező kis osztály (például memóriafogyasztást) túlterhelését, és lehetővé teszi, hogy mindenki megosztson egy osztályt (meta-osztály).
A programozásban néha nagy számú apró szemcsésű osztálypéldányt kell előállítani az adatok ábrázolásához, és ha azt tapasztaljuk, hogy ezek a példányok lényegében ugyanaz a túlterhelés néhány paraméter kivételével, akkor az osztályok megmutatandó száma jelentősen csökkenthető. Ha ezeket a paramétereket át tudod vinni az osztály példányon, és továbbítani őket, amikor a metódus hívásakor, jelentősen csökkentheted az egyes példányok számát megosztással.
És akkor mi van, ha JavaScriptben alkalmazod a meta módot? Kétféleképpen alkalmazható: az első az adatrétegre vonatkozik, főként számos hasonló objektumra a memóriában; A második a DOM rétegre kerül, amely a központi eseménymenedzserben használható, hogy elkerülje az eseményfogantyúk csatolását az összes szülő konténer gyermekeleméhez.
Élvezd a metaverzumot és az adatrétegeket
A Flyweight két fontos fogalma létezik – belső állapot intrinzikus és külső állapot extrinsic, a belső állapotot belső módszerek segítségével kezelik az objektumban, és külső információk külsőleg törölhetők vagy menthetők.
Őszintén szólva, először egy eredeti modellt fogunk meg, majd különböző helyzetekben és környezetekben, majd specifikus modelleket készítünk a saját jellemzőkkel, nyilvánvalóan itt különböző új objektumokat kell generálni, így a gyári mód gyakran megjelenik a Flyweight módban, a Flyweight belső állapotát használják megosztásra, és a Flyweight gyár felelős egy Flyweight készlet (mintakészlet) fenntartásáért, hogy tárolja a belső állapot objektumait.
Használd a Yuanyuan módot
Mutassuk be, hogy ha lenne egy könyvtárunk, amely minden könyvet kezelhet, az egyes könyvek metaadatai előzetesen így néznének ki:
ID
Cím
Szerző
Műfaj
Oldalszám
Kiadói azonosító
ISBN
Meg kell határoznunk azt is, hogy mikor és ki kölcsönözte az egyes könyveket, valamint a visszaküldési dátumot és elérhetőséget:
kinézésDátum
kizárásTagtag
dueReturnDate
Elérhetőség
Mivel a könyvobjektum a következő kódra van állítva, jegyezzük meg, hogy a kódot még nem optimalizálták:
A program eleinte jó lehet, de idővel a könyvek száma nagy mennyiségben növekedhet, és minden könyvnek más verziója és mennyisége van, és azt fogod tapasztalni, hogy a rendszer egyre lassabb lesz. Több ezer könyvtárgy memóriában elképzelhető, és ezeket optimalizálni kell a megosztási móddal.
Az adatokat kétféle adatra oszthatjuk: belső és külsőre, a könyvobjektumhoz kapcsolódó adatok (cím, szerző stb.) belső attribútumoknak tulajdoníthatók, míg (checkoutMember, dueReturnDate stb.) külső attribútumoknak is tulajdoníthatók. Így a következő kód ugyanazt a tárgyat oszthatja meg ugyanabban a könyvben, mert bárki is kölcsönveszi a könyvet, amíg a könyv ugyanaz, az alapvető információk ugyanazok:
Definiáljuk az alapgyárat
Definiáljunk egy alapvető gyárat, amely ellenőrzi, hogy a könyv objektuma korábban készült-e, visszaadjuk, ha van, és újraalkotjuk és tároljuk, ha nem, így biztosítva, hogy minden könyvtípushoz csak egy objektumot hozzunk létre:
Külső státusz kezelése
A külső állapot viszonylag egyszerű, kivéve a könyvet, amit befoglaltunk, minden mást itt kell kezelni:
Így ugyanazt a könyv információját menthetjük el egy könyvkezelő objektumban, és csak egy példányt; Az előző kódhoz képest sok memóriát mentek el.
Élvezd a meta módot és a DOM-ot
Nem fogok sokat mondani a DOM buborékolási esetről, úgy hiszem, mindenki már tudja, hozzunk két példát.
1. példa: Központosított incidenskezelés
Például, ha sok hasonló elem vagy struktúra (például menük vagy több li in ul), amelyek figyelni kell az ő kattintási eseményét, akkor minden egyes elemet be kell kötnünk az eseménykötéshez, ha nagyon-nagyon sok elem van, akkor a teljesítmény elképzelhető, és a bubbling ismerete mellett ha bármelyik gyerekelemnek van eseménykiváltója, akkor az esemény a magasabb elemre buborékolódik a trigger után, így ezzel a funkcióval használhatjuk a Xiangyuan módot. Nyomon követhetjük ezeknek az elemeknek az övelemeinek eseményeit, majd meghatározhatjuk, hogy melyik gyermekelemnek vált ki eseménye, mielőtt további műveleteket folytatnánk.
Itt példaként kombináljuk a jQuery bind/unbind módszereit.
HTML:
JavaScript:
2. példa: A Xiangyuan mód alkalmazása a teljesítmény javítására
Egy másik példa, ami még mindig kapcsolódik a jQuery-hez, általában az elemobjektumot az esemény visszahívási függvényében használjuk, gyakran használjuk a $(this) formát, valójában ismételten új objektumot hoz létre, mivel ez a callback függvényben már maga a DOM elem, a következő kódot kell használnunk:
Valójában, ha valami olyasmit kell használnunk, mint a $(this), akkor megvalósíthatjuk a saját verziót is az egypéldányos mintának, például létrehozhatunk egy olyan függvényt, mint a jQuery.signle(this), amely visszaadja magát a DOM elemet:
Hogyan kell használni:
Ez visszaadja magát a DOM elemet úgy, ahogy van, anélkül, hogy jQuery objektumot hozna létre.
összefoglalás
A flyweight mód egy olyan mód, amely javítja a program hatékonyságát és teljesítményét, ami jelentősen felgyorsítja a program futási sebességét. Számos alkalmazás létezik: például, ha egy adatbázisból egy sorozat stringet szeretnél olvasni, amelyek közül sok duplikátum, akkor ezeket a stringeket egy Flyweight poolban tárolhatjuk.
Ha egy alkalmazás sok objektumot használ, és ezek a sok objektum nagy tárolási örömet okoz, fontolóra kell vennie a megosztási módot; Ha törlöd az objektum külső állapotát, sok objektumcsoportot helyettesíthetsz viszonylag kevés megosztott objektumra, és fontolóra veheted a Xiangyuan mód használatát.
Hivatkozási cím:http://www.addyosmani.com/resour ... ok/#detailflyweight
|
Előző:Ajánlj 3 weboldalt, ahol ikonikonokat találhatszKövetkező:Várakozódó üzenetek, üzeneteksorba állítva, üzenet...
|
