Flyweight – бұл компьютерлік бағдарламалауда жадты үнемдеуге көмектесетін дизайн үлгісі. Объектілер арасында мәліметтерді бөлісу арқылы тиімділік арттырады.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Объектілер үшін бағдарламалық жасақтама үлгісі
Software design pattern for objects
Компьютерлік бағдарламалауда, жеңілдетілген бағдарламалық жасақтама үлгісі – жадты үнемдеу үшін өзінің кейбір деректерін басқа ұқсас объектілермен бөлісетін объектіні білдіреді. Жеңілдетілген үлгі – GoF дизайнының жиырма үш танымал үлгілерінің бірі. Бұл үлгілер икемді, объектіге бағытталған бағдарламалық жасақтаманы құруға көмектеседі, оны іске асыру, өзгерту, тестілеу және қайта пайдалану оңай. Басқа контексттерде дерек құрылымдарын ортақ пайдалану идеясы хэш консинг деп аталады. Бұл термин алғаш рет Пол Кальдер мен Марк Линтон 1990 жылы WYSIWYG құжат редакторында глифтік ақпаратты тиімді өңдеу үшін қолданылған. Дегенмен, ұқсас техникалар 1988 жылдан бері басқа жүйелерде де қолданылып келеді.
In computer programming, the flyweight software design pattern refers to an object that minimizes memory usage by sharing some of its data with other similar objects. The flyweight pattern is one of twenty three well known GoF design patterns. These patterns promote flexible object oriented software design, which is easier to implement, change, test, and reuse. In other contexts, the idea of sharing data structures is called hash consing. The term was first coined, and the idea extensively explored, by Paul Calder and Mark Linton in 1990 to efficiently handle glyph information in a WYSIWYG document editor. Similar techniques were already used in other systems, however, as early as 1988.
Жүзеге асырудың егжей-тегжейлі сипаттамасы
Ұш салмағы үлгісін іске асырудың бірнеше тәсілі бар. Мысалы, өзгертілгіштік: сыртқы ұш салмағы күйін сақтайтын нысандар өзгертілуі мүмкін бе. Өзгертілмейтін нысандарды оңай бөлісуге болады, бірақ күйде өзгеріс болған сайын жаңа сыртқы нысандар құру қажет. Ал өзгертілгіш нысандар күйді бөлісе алады. Өзгертілгіштік, ескі, пайдаланылмаған нысандарды кэштеу және қайта инициализациялау арқылы нысандарды қайта пайдалануға жағдай жасайды. Күйі өте өзгергіш болғанда бөлісу көбінесе мүмкін емес. Басқа маңызды мәселелерге: ұш салмақты алу (соңғы клиент оған қалай қол жеткізеді), кэштеу және параллелизм жатады.
There are multiple ways to implement the flyweight pattern. One example is mutability: whether the objects storing extrinsic flyweight state can change. Immutable objects are easily shared, but require creating new extrinsic objects whenever a change in state occurs. In contrast, mutable objects can share state. Mutability allows better object reuse via the caching and re initialization of old, unused objects. Sharing is usually nonviable when state is highly variable. Other primary concerns include retrieval (how the end client accesses the flyweight), caching and concurrency.
Қайта алу
Ұш салмақты объектілерді жасау немесе қайта пайдалану үшін фабрика интерфейсі көбінесе күрделі жатқан жүйенің сыртқы көрінісі болып табылады. Мысалы, фабрика интерфейсі әдетте, Ұш салмақтықтарды (flyweights) құру үшін жаһандық қолжетімділікті қамтамасыз ету мақсатында жеке дана (singleton) ретінде іске асырылады. Жалпы айтқанда, іздеу алгоритмі фабрика интерфейсі арқылы жаңа объектіні сұраудан басталады. Сұрау әдетте, объектінің түріне қарай тиісті кэшке жіберіледі. Егер сұрау кэштегі объектімен қанағаттандырылса, ол қайта инициализацияланып қайтарылуы мүмкін. Әйтпесе, жаңа объект құрылады. Егер объект бірнеше сыртқы құрамдас бөліктерге бөлінген болса, олар объекті қайтарылмас бұрын біріктіріледі.
The factory interface for creating or reusing flyweight objects is often a facade for a complex underlying system. For example, the factory interface is commonly implemented as a singleton to provide global access for creating flyweights. Generally speaking, the retrieval algorithm begins with a request for a new object via the factory interface. The request is typically forwarded to an appropriate cache based on what kind of object it is. If the request is fulfilled by an object in the cache, it may be reinitialized and returned. Otherwise, a new object is instantiated. If the object is partitioned into multiple extrinsic sub components, they will be pieced together before the object is returned.
Кэштеу
Ұш салмақты нысандарды кэшке сақтаудың екі тәсілі бар: күтіліп тұратын және күтілмейтін кэштер. Күйде жиі өзгеріс болатын нысандарды FIFO құрылымымен кэшке сақтауға болады. Бұл құрылым кэште іздеу қажеттілігін жоққа шығарып, пайдаланылмаған нысандарды сақтайды. Керісінше, күтілмейтін кэштерде алдын ала шығындар аз: кэштердегі нысандар компиляция немесе жүктелу кезінде бірден жасалады. Нысандар кэшке орналасқаннан кейін, нысанды алу алгоритмі күтіліп тұратын кэштің қосу/алу операцияларына қарағанда көп жүктемеге ие болуы мүмкін. Өзгермейтін күйі бар сыртқы нысандарды алу кезінде, қалаған күйдегі нысанды кэште іздеу жеткілікті. Егер мұндай нысан табылмайтын болса, сол күйдегі нысан инициализациялануы керек. Өзгермелі күйі бар сыртқы нысандарды алу кезінде, пайдаланылмаған нысанды қайта инициализациялау үшін кэште іздеу қажет, егер пайдаланылған нысан табылмайтын болса. Егер пайдаланылмаған нысан болмаса, жаңа нысан жасалып, кэшке қосылуы керек. Сыртқы нысанның әрбір бірегей кіші класы үшін жеке кэштерді пайдалануға болады. Көптеген кэштерді әр кэшке бірегей іздеу алгоритмін қосып, жеке-жеке оңтайландыруға болады. Бұл нысанды кэштеу жүйесі жауапкершілік тізбегі үлгісімен қапталануы мүмкін, бұл компоненттер арасындағы байланыстың әлсіздігін қамтамасыз етеді.
There are two ways to cache flyweight objects: maintained and unmaintained caches. Objects with highly variable state can be cached with a FIFO structure. This structure maintains unused objects in the cache, with no need to search the cache. In contrast, unmaintained caches have less upfront overhead: objects for the caches are initialized in bulk at compile time or startup. Once objects populate the cache, the object retrieval algorithm might have more overhead associated than the push/pop operations of a maintained cache. When retrieving extrinsic objects with immutable state one must simply search the cache for an object with the state one desires. If no such object is found, one with that state must be initialized. When retrieving extrinsic objects with mutable state, the cache must be searched for an unused object to reinitialize if no used object is found. If there is no unused object available, a new object must be instantiated and added to the cache. Separate caches can be used for each unique subclass of extrinsic object. Multiple caches can be optimized separately, associating a unique search algorithm with each cache. This object caching system can be encapsulated with the chain of responsibility pattern, which promotes loose coupling between components.