{"id":1975,"date":"2020-09-20T12:24:06","date_gmt":"2020-09-20T09:24:06","guid":{"rendered":"https:\/\/www.cs.ubbcluj.ro\/~bufny\/?p=1975"},"modified":"2022-01-10T00:18:22","modified_gmt":"2022-01-09T22:18:22","slug":"should-decorators-preserve-the-component-interface","status":"publish","type":"post","link":"https:\/\/www.cs.ubbcluj.ro\/~bufny\/should-decorators-preserve-the-component-interface\/","title":{"rendered":"Should Decorators Preserve the Component Interface?"},"content":{"rendered":"

Preprint, arXiv:2009.06414<\/a> [cs.SE], September 2020.<\/p>\n

Cite as<\/strong><\/p>\n

V. Niculescu, A. Sterca, D. Bufnea, \"Should Decorators Preserve the Component Interface?\", arXiv:2009.06414 [cs.SE], September 2020<\/pre>\n
Full paper<\/strong><\/p>\n
\"\" Should Decorators Preserve the Component Interface?<\/a><\/p>\n
Authors<\/strong><\/p>\n
Virginia Niculescu*, Adrian Sterca*, Darius Bufnea*
\n* Department of Computer Science, Faculty of Mathematics and Computer Science, Babe\u0219-Bolyai University of Cluj-Napoca, Romania<\/p>\n
Abstract<\/strong>
\nDecorator design pattern is a well known pattern that allows dynamical attachment of additional functionality to an object. Decorators have been proposed as flexible alternative to subclassing for extending functionality. Still, the Decorator pattern has certain limitations, especially related to the fact that in its classical form it is constrained to a single interface, which is implicitly defined by the type of the concrete components that we intend to decorate. Another problem associated to the Decorator pattern is related to the linear composition of the decorations, which could lead to problems in accessing the newly added responsibilities. In this context, the paper presents variants of the Decorator pattern: MixDecorator and D2Decorator, and a variant specific only to C++ language based on templates – HybridDecorator. MixDecorator could be considered a new enhanced version of the Decorator pattern that eliminates some constraints of the Decorator pattern, but also it could be used as a base of a general extension mechanism. The main advantage of using MixDecorator is that it allows direct access to all newly added responsibilities, and so, we may combine different interface-responsibilities (newly added public methods) and operate with them directly and in any order, hiding the linear composition of the decorations. D2Decorator is a variant based on a double-dispatch mechanism. The C++ metaprogramming mechanism based on templates allows an interesting hybrid variant of the Decorator – HybridDecorator, which mixes on-demand defined inheritance with composition. Using these variants of the Decorator pattern we are not longer limited to one single interface; the set of the messages that could be sent to an object could be enlarged, and so, we may consider that using them, we can dynamically change the type of objects.<\/p>\n
Key words<\/strong><\/p>\n
OOP; design patterns; decorator; interface; responsibility; extensibility.<\/p>\n
BibTeX bib file<\/strong><\/p>\n
\"\" mixdecorator2020.bib<\/a><\/p>\n
<\/pre>\n
References<\/strong><\/p>\n