{"id":78,"date":"2021-03-12T01:12:54","date_gmt":"2021-03-11T23:12:54","guid":{"rendered":"http:\/\/www.cs.ubbcluj.ro\/~vniculescu\/?page_id=78"},"modified":"2021-03-21T19:50:51","modified_gmt":"2021-03-21T17:50:51","slug":"mixdecorator-an-enhaced-version-of-the-decorator-pattern","status":"publish","type":"page","link":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/mixdecorator-an-enhaced-version-of-the-decorator-pattern\/","title":{"rendered":"MixDecorator: An enhaced version of the Decorator pattern"},"content":{"rendered":"<h2>TOC<\/h2>\n<ul>\n<li><a href=\"#Decorator_pattern\">Decorator<\/a><\/li>\n<li><a href=\"#MixDecorator_Pattern\">MixDecorator &#8211; Definition<\/a><\/li>\n<li><a href=\"#Extensions_with_other_responsibilities\">MixDecorator &#8211; Extensions<\/a><\/li>\n<li><a href=\"#Implementation\">MixDecorator &#8211; Implementation<\/a><\/li>\n<li><a href=\"#MixDEcorator_-_Advantages\">MixDecorator &#8211; Advantages<\/a><\/li>\n<\/ul>\n<p><span style=\"font-weight: bold; font-style: italic;\">MixDecorator<\/span> is enhanced version of the classical <span style=\"font-style: italic;\">Decorator<\/span> pattern defined in Gang of Four book.<\/p>\n<p>The classical <span style=\"font-style: italic;\">Decorator<\/span> pattern offers a solution to extend the functionality of an object in order to modify its behavior. Still, when we want to add new responsibilities, and not just to change the behavior of an existing one, the classical Decorator pattern allows us to define such a decoration, but this is accessible only if it is the last added one.<\/p>\n<p><span style=\"font-style: italic;\">MixDecorator<\/span> does not just eliminate some constraints of the classical pattern (e.g. limitation to one interface), but also allows it to be used as a base for a general extension mechanism. This version introduces significant flexibility and abstraction.<\/p>\n<p>Using it, we may:<\/p>\n<ul>\n<li>combine different responsibilities,<\/li>\n<li>have direct access to all, and<\/li>\n<li>operate with them in any order<\/li>\n<\/ul>\n<p><a name=\"Decorator_pattern\"><\/a><\/p>\n<h2>Decorator pattern<\/h2>\n<p><img loading=\"lazy\" width=\"495\" height=\"347\" class=\"alignleft size-full wp-image-84\" style=\"width: 50%;\" src=\"http:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Decorator.jpg\" alt=\"\" srcset=\"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Decorator.jpg 495w, https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Decorator-300x210.jpg 300w, https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Decorator-200x140.jpg 200w\" sizes=\"(max-width: 495px) 100vw, 495px\" \/>The classical <a href=\"http:\/\/www.oodesign.com\/decorator-pattern.html\" target=\"_blank\" rel=\"noopener\">Decorator pattern<\/a> offers a solution to extend the functionality of an object in order to modify its behaviour.<\/p>\n<p>It is usually agreed that decorators and the original class object share a common set of operations:<\/p>\n<p>multiple decorators can be stacked on top of each other, each time adding new functionality to the overridden method(s).<\/p>\n<h3>Limitations of the classical Decorator pattern.<\/h3>\n<p>Theoretically, we may obtain any combination of decorations but we only have the base class interface available.<\/p>\n<p>So, if there are some responsibilities that are really new responsibilities (that changes the object<\/p>\n<p>interface) and they are not used just to alter the behavior of the operations defined in the base class, they will be accessible only if the last decoration is the one that defines them.<\/p>\n<p>More concretely, if responsibility f1 is a new interface responsibility and it is defined in the class Decorator1, then the corresponding message could be sent only to an object that has the Decorator1 decoration, but also only if this is the last added decoration; the following Java code snippet emphasizes this:<\/p>\n<pre class=\"lang:java\">IComponent o = new Decorator1 ( new Decorator2 ( new ConcreteComponent ())));\r\n(( Decorator1 ).o).f1();\r\nIComponent oo = new Decorator2 ( new Decorator1 (new ConcreteComponent ())));\r\n\/\/ (( Decorator1 ).oo).f1(); ERROR\r\n(( Decorator1 )oo.getBase()).f1(); \/\/ an improper solution\r\n<\/pre>\n<p>The emphasized solution has obviously several drawbacks:<\/p>\n<ul>\n<li>we have to apply an additional operation that allows decoration removal getBase(); in case we don&#8217;t have it, there is no solution;<\/li>\n<li>the functionality added by Decorator2 is lost (the behavior modification of the base operations brought by Decorator2);<\/li>\n<li>if there are several decorations that should be removed then several additional operations are necessary;<\/li>\n<li>if we don&#8217;t know the exact position (order) of the searched decoration, the code becomes very complex (a kind of reflection should be used);<\/li>\n<\/ul>\n<p>In fact, removing the last decorations in order to reveal functionality is not a real solution since it breaks the way in which decorated objects are supposed to be used. Also, it is an ad-hoc workaround that is based on knowing the order in which decorations were added.<\/p>\n<p><span style=\"font-weight: bold; font-style: italic;\">Concrete example: Java Input Streams<\/span><\/p>\n<p>We may consider the classes in Java IO streams library, where <span style=\"font-style: italic;\">Decorator \/span&gt; pattern is used.<\/span><\/p>\n<p><span style=\"font-style: italic;\">FilterInputStream<\/span> corresponds there to DecoratorBase and it&#8217;s derived from I<span style=\"font-style: italic;\">nputStream <\/span>that corre sponds to <span style=\"font-style: italic;\">IComponent<\/span>. There are several decoration classes derived from FilterInputStream such as <span style=\"font-style: italic;\">PushBackInputStream<\/span> that defines a method unread(), which is not defined in the <span style=\"font-style: italic;\">FilterInputStream<\/span> interface; <span style=\"font-style: italic;\">BufferedInputStream <\/span>that just alters the behavior of the standard <span style=\"font-style: italic;\">InputStream<\/span> interface; or CheckedInputStream that maintains a checksum of the data being read and<br \/>\nallows using it based on the method <span style=\"font-style: italic;\">getChecksum<\/span>.<\/p>\n<p>We may combine them, and decorate a concrete stream &#8211; e.g. <span style=\"font-style: italic;\">FileInputStream<\/span> &#8211; first with <span style=\"font-style: italic;\">CheckedInputStream<\/span>, and then with <span style=\"font-style: italic;\">BufferedInputStream <\/span>or\/and with <span style=\"font-style: italic;\">PushBackInputStream<\/span>; then the <span style=\"font-style: italic;\">getChecksum <\/span>method is not directly<br \/>\navailable.<\/p>\n<pre class=\"lang:java\">PushbackInputStream pi = new PushbackInputStream (\r\n   new BufferedInputStream (\r\n      new CheckedInputStream ( new FileInputStream (\" input \"), new CRC32 ())));\r\n\/\/ pi. getChecksum (); ERROR\r\n<\/pre>\n<p><a name=\"MixDecorator_Pattern\"><\/a><\/p>\n<h2>MixDecorator Pattern<\/h2>\n<p><span style=\"font-weight: bold; font-style: italic;\">Synopsis.<\/span> Attach a set of additional responsibilities to an object dynamically. Allow access to all added responsibilities. Provide a flexible alternative to subclassing for extending objects functionality and their types, too (extending the set of messages that could be sent to them).<\/p>\n<p><span style=\"font-weight: bold; font-style: italic;\">Context. <\/span>You want to add a combination of additional capabilities onto an object. However, the additional capabilities you want are highly variable, and could extend the interface of the base object.<\/p>\n<p>You want all additional responsibilities to be directly available.<\/p>\n<p><span style=\"font-weight: bold; font-style: italic;\">Problem. <\/span>The classical Decorator pattern offers a solution to extend (decorate) the functionality of a certain object in order to modify its behavior. It is usually agreed that decorators and the original class object share a common interface. The problem appears when we want to add a new interface responsibility, and not just to change the behavior of an existing<br \/>\none. Such a decoration could bedefined, but it is accessible only if it is the last added one.<\/p>\n<p><span style=\"font-weight: bold; font-style: italic;\">Forces.<\/span><\/p>\n<ul>\n<li>Adding responsibilities should be transparent to clients.<\/li>\n<li>All responsibilities which are added at some point are directly accessible to the client.<\/li>\n<li>Simple and direct call for all decoration methods, not dependent of the exact position (order) of<\/li>\n<li>the decoration where the desired responsibility is defined.<\/li>\n<li>It should be easy to change, e.g. withdraw or adding, responsibilities.<\/li>\n<li>Good effciency, and easily extendable.<\/li>\n<\/ul>\n<p><span style=\"font-weight: bold; font-style: italic;\">Solution.<\/span><br \/>\nThe structure of the <span style=\"font-style: italic;\">MixDecorator<\/span> is inspired by the <span style=\"font-style: italic;\">Decorator<\/span> but there are several important differences that allow the achievement of the &#8216;forces&#8217;. As for simple decorators we enclose the subject in another object, the decorator object, but the decorator could have an interface that extends the general component interface. The decorator forwards requests to the subject while performing additional actions before and after forwarding.<\/p>\n<p>The solution structure is:<\/p>\n<p><img loading=\"lazy\" width=\"675\" height=\"558\" class=\"alignleft size-full wp-image-89\" style=\"width: 50%;\" src=\"http:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/MixDecoratorDiagram.png\" alt=\"\" srcset=\"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/MixDecoratorDiagram.png 675w, https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/MixDecoratorDiagram-300x248.png 300w, https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/MixDecoratorDiagram-660x546.png 660w\" sizes=\"(max-width: 675px) 100vw, 675px\" \/><\/p>\n<p>This makes a clear separation between <small><span style=\"font-family: Courier New,Courier,monospace;\"><span style=\"font-weight: bold;\">IComponent <\/span><\/span><\/small>and <small><span style=\"font-weight: bold;\">DecoratorBase<\/span><\/small> by introducing a general IDecorator interface that extends <small><span style=\"font-family: Courier New,Courier,monospace;\"><span style=\"font-weight: bold;\">IComponent<\/span> <\/span><\/small>and adds only <small><span style=\"font-family: Courier New,Courier,monospace;\">getBase()<\/span><\/small>method (this method is considered mandatory).<\/p>\n<p>The concrete class <small><span style=\"font-weight: bold; font-family: Courier New,Courier,monospace;\">DecorateBase<\/span><\/small> has almost the same deffnition as the corresponding class from the classical <span style=\"font-style: italic;\">Decorator <\/span>(the difference is the additional method <small><span style=\"font-family: Courier New,Courier,monospace;\">getBase()<\/span><\/small>).<\/p>\n<p>For a particular application, after the new responsibilities are inventoried, then particular <small><span style=\"font-weight: bold;\">IDecoratorOperations<\/span><\/small> and <small><span style=\"font-weight: bold;\">ConcreteDecoratorBase<\/span><\/small> are defined. <small><span style=\"font-weight: bold;\">IDecoratorOperations<\/span><\/small> defines the methods that correspond to all new responsibilities. As it can be seen from the figure, <small><span style=\"font-weight: bold;\">ConcreteDecoratorBase<\/span><\/small> is derived from <small><span style=\"font-weight: bold;\">DecoratorBase<\/span><\/small> but also implements <small><span style=\"font-weight: bold;\">IDecoratorOperations<\/span><\/small>.<\/p>\n<p>The concrete class <small><span style=\"font-weight: bold;\">ConcreteDecoratorBase<\/span><\/small> gives a definition for each new added responsibility. It implements <small><span style=\"font-weight: bold;\">IDecoratorOperations <\/span><\/small>and extends <small><span style=\"font-weight: bold;\">DecoratorBase<\/span><\/small>. The corresponding code hides a recursion that is used for searching the method (for example <small><span style=\"font-family: Courier New,Courier,monospace;\">f<\/span><span style=\"font-family: Courier New,Courier,monospace;\">1()<\/span><\/small>) that defines the new responsibility.<\/p>\n<p>In order to better explain the pattern we will give some implementation details in Java 8.<\/p>\n<pre class=\"lang:java\">public class ConcreteDecoratorBase extends DecoratorBase implements IDecoratorOperations {\r\n   public ConcreteDecoratorBase ( IComponent base )\r\n   { super ( base ); }\r\n   public void f1 () throws UnsupportedFunctionalityException {\r\n       try {\r\n               (( IDecoratorOperations ) getBase ()). f1 (); }\r\n       catch ( ClassCastException e){ \/\/ if base is not a decorator but a concrete component\r\n               throws new UnsupportedFunctionalityException (\"f1\");\r\n       }\r\n    }\r\n    . . .\r\n}\r\n<\/pre>\n<p>(Instead of<small><span style=\"font-family: Courier New,Courier,monospace;\"> try-catch <\/span><\/small>mecahanism, <small><span style=\"font-family: Courier New,Courier,monospace;\">instanceof<\/span><\/small> operator could be used).<\/p>\n<p>The following code snippet emphasizes the forces fulfillment; the execution throws no exception, and it can be noticed that, for example, f3() could be called even if <small><span style=\"font-weight: bold;\">Decorator3<\/span><\/small> is the first added decoration<\/p>\n<pre class=\"lang:java\">IComponent c = new ConcreteComponent ();\r\nIDecoratorOperations d = new Decorator1 ( new Decorator2 ( new Decorator3 (c )));\r\nd.operation ();\r\nd.f3 ();     d.f1 ();     d.f2 ();\r\n<\/pre>\n<p><a name=\"Extensions_with_other_responsibilities\"><\/a><\/p>\n<h2>Extensions with other responsibilities<\/h2>\n<p>If other possible responsibilities are discovered as being appropriate to be used, these could be added using the following steps:<\/p>\n<ol>\n<li>(optional) Provide an adaptation that assures that all the responsibilities either added in the first design iteration or in the next, could be combined in any order.<br \/>\nDefine a new interface \u2013 <small><span style=\"font-weight: bold;\">IDecoratorOperations_Extended<\/span><\/small> that extends <small><span style=\"font-weight: bold;\">IDecoratorOperations<\/span><\/small> interface, and defines the desired new responsibilities.<\/li>\n<li>(optional) Provide an adaptation that assures that all the responsibilities either added in the first design iteration or in the next, could be combined in any order.<br \/>\nDefine a class \u2013 ConcreteDecoratorBase_Extended that extends ConcreteDecoratorBase and implements <small><span style=\"font-weight: bold;\">IDecoratorOperations_Extended<\/span><\/small>.<\/li>\n<li>(optional) Provide an adaptation that assures that all the responsibilities either added in the first design iteration or in the next, could be combined in any order.<\/li>\n<\/ol>\n<p><img loading=\"lazy\" width=\"786\" height=\"558\" class=\"alignleft size-full wp-image-94\" style=\"width: 50%;\" src=\"http:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Extensions.jpg\" alt=\"\" srcset=\"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Extensions.jpg 786w, https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Extensions-300x213.jpg 300w, https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Extensions-768x545.jpg 768w, https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-content\/uploads\/Extensions-660x469.jpg 660w\" sizes=\"(max-width: 786px) 100vw, 786px\" \/><\/p>\n<p>The specified adaptation could be done using, for example, <span style=\"font-style: italic;\">Adapter<\/span> pattern.<\/p>\n<p>The previous decoration classes are adapted to the new extended interface.<\/p>\n<p>For example the class <small><span style=\"font-weight: bold;\">Decorator2_Adapted<br \/>\n<\/span><\/small>is derived from <small><span style=\"font-weight: bold;\">Decorator2<\/span><\/small>, and implements <small><span style=\"font-weight: bold;\">IDecoratorOperations_Extended<\/span><\/small>; no method overriding is necessary.<\/p>\n<p>But this also requires a basic implementation of the methods defined in <small><span style=\"font-weight: bold;\">IDecoratorOperations_Extended<\/span><\/small>.<\/p>\n<p>Java 8 introduces <a href=\"https:\/\/docs.oracle.com\/javase\/tutorial\/java\/IandI\/defaultmethods.html\">default methods<\/a> in interfaces.The implementation of the method f4() in <small><span style=\"font-weight: bold;\">IDecoratorOperations_Extended<\/span><\/small> could be defined in Java as:<\/p>\n<pre class=\"lang:java\">   default void f4 () throws UnsupportedFunctionalityException {\r\n       try { (( IDecoratorOperations_Extended ) getBase ()). f4 (); }\r\n       catch ( ClassCastException e){\r\n           throw new UnsupportedFunctionalityException (\"f4\"); }\r\n   }\r\n<\/pre>\n<p>This definition assures that the first set of decorations could be combined with the new decorations in any order,inclusive to wrap around the new decorations (optional step (3)).<\/p>\n<p>The implementation of the <small><big>class<\/big><span style=\"font-weight: bold;\"> ConcreteDecoratorBase_Extended<\/span><\/small> is similar to that of <small><span style=\"font-weight: bold;\">ConcreteDecoratorBase<\/span><\/small>.<\/p>\n<p>Usage example:<\/p>\n<pre class=\"lang:java\">   IComponent c = new ConcreteComponent ();\r\n   IDecoratorOperations d31 = new Decorator3 ( new Decorator1 (c);\r\n   IDecoratorOperations_Extended d431 = new Decorator4 ( d31 );\r\n   IDecoratorOperations_Extended d2431 = new Decorator2_Adapted ( d431 );\r\n   d431.f3 ();     d431.f4 ();     d431.f1 ();     d2431.f2 ();     d2431.f4 ();\r\n<\/pre>\n<p>The code produces the correct execution of all the methods.<\/p>\n<p><a name=\"Implementation\"><\/a><\/p>\n<h2>Implementation<\/h2>\n<p>The general structure of the pattern could be easily implemented in any object-oriented language.<\/p>\n<p>In order to allow new <span style=\"font-weight: bold; font-style: italic;\">decoration extensions<\/span>, there is an <span style=\"text-decoration: underline;\">implementation requirement<\/span> defined by the possibility of adding new methods to an interface (to add a set of methods to <small><span style=\"font-weight: bold;\">IDecoratorOperations<\/span><\/small> interface), and also to provide a basic implementation for them.<\/p>\n<p>Classically, this is done based on multiple inheritance.<\/p>\n<p>So, a language as C++ or any other that allows multiple inheritance lead to a simple implementation, where <small><span style=\"font-weight: bold;\">IDecoratorOperations_Extended<\/span><\/small> is defined as an abstract class.<\/p>\n<p>Other mechanisms \u2013 specific to the target language \u2013 could be investigated.<\/p>\n<p>An example is provided by the <span style=\"font-weight: bold; font-style: italic;\">Java extended interfaces<\/span> (or virtual extension methods &#8211; as they are also called).<\/p>\n<p>They are based on defining default implementations inside interfaces (the implementation details for our casewere given in the previous section). It is also considered that Java 8 interfaces can be exploited to introduce a trait-oriented programming style.<\/p>\n<p>Also, the implementation of the <span style=\"font-style: italic;\">MixDecorator<\/span> could be simplified by considering only<small><span style=\"font-weight: bold;\"> IDecoratorOperations<\/span><\/small> without <small><span style=\"font-weight: bold;\">ConcreteDecoratorBase<\/span><\/small>.<\/p>\n<p>In Java 8 this would be an interface with default methods (with the same definitions as they are now in<small><span style=\"font-weight: bold;\"> ConcreteDecoratorBase)<\/span><\/small>.<\/p>\n<p>In <span style=\"font-weight: bold; font-family: Times New Roman,Times,serif;\">C#<\/span> the pattern could be implemented based on <a href=\"https:\/\/msdn.microsoft.com\/en-us\/\/library\/bb383977.aspx\" target=\"_blank\" rel=\"noopener\">extension methods<\/a>. Using \u201cextension methods\u201d we are able to add new methods to a class after the complete definition of the class. They allow the extension of an existing type with new functionality, without having to sub-class or recompile the old type. The mechanism allows only static binding and so the methods that could be added to a class cannot be declared virtual. In fact, an extension method is a static method defined in a non-generic static class, and can be invoked using an instance method syntax. If we use them in C#, we may add a static class <small><span style=\"font-weight: bold;\">Decorator_Extension <\/span><\/small>where the methods f4(), f5() are defined as extension methods. The class <small><span style=\"font-weight: bold;\">Decorator_Extension <\/span><\/small>provides extension for <small><span style=\"font-weight: bold;\">IDecoratorOperations<\/span><\/small>:<\/p>\n<pre class=\"lang:c#\">   public static class Decorator_Extension {\r\n       public static void f4( this IDecoratorOperations db) {\r\n           try\r\n               { (( Decorator4 )db ). f4 (); }\r\n           catch ( InvalidCastException e)\r\n               { try { (( IDecoratorOperations )db. getBase ()). f4 (); }\r\n                   catch ( InvalidCastException ee)\r\n                       { throw new UnSupportedFunctionalityException (\"f4\");}\r\n                }\r\n       }\r\n... }\r\n<\/pre>\n<p>The code defines a recursion that it\u2019s stopped either if the current decoration defines the invoked method or by throwing an exception if no decoration that defines such a method was found.<\/p>\n<p>In Java, the verification of the first case is implicitly done based on polymorphic call.<\/p>\n<p>With this C# solution, no adaptation of the first decorator classes is needed<\/p>\n<p><a style=\"font-weight: bold;\" name=\"MixDEcorator_-_Advantages\"><\/a><\/p>\n<h2>MixDEcorator &#8211; Advantages<\/h2>\n<ul>\n<li>The linear combination of the decorations is hidden. The final object could be seen as an object with a set of additional responsibilities. This way we may consider that we extend the type of an object (by extending the set of messages that could be sent to it) without defining new classes.<\/li>\n<li>The component and its decorators are decoupled. The author of the component does not need to do anything special for it to be decorated.<\/li>\n<li>Added behavior could be used in any combination, without any additional operation: such as withdrawing decorations.<\/li>\n<li>Clients can choose what capabilities they want by sending messages to the object that has the appropriate decoration.<\/li>\n<\/ul>\n<h2>Examples<\/h2>\n<p>The applications that were designed based on the classical Decorator, and which define new responsibilities for the decorated objects, could be improved by using <span style=\"font-style: italic;\">MixDecorator.<\/span><\/p>\n<p>The definition of <span style=\"font-weight: bold; font-style: italic;\">Java IO streams<\/span> is such an example.<\/p>\n<p>If a method of type <small style=\"font-weight: bold;\">getBase()<\/small> would be provided in <small style=\"font-weight: bold;\">FilterInputStream<\/small> then <span style=\"font-style: italic;\">MixDecorator <\/span>could be used instead of simple <span style=\"font-style: italic;\">Decorator<\/span>, and so we could eliminate the constraints of the current implementation.<\/p>\n<p>Many other similar situations could be found, where decorations imply also adding new operations.<\/p>\n<h2>Framework for collection data structures with features<\/h2>\n<p>We proposed in [2] a design based on <span style=\"font-style: italic;\">Decorator<\/span> pattern for frameworks of collection data structures. The implementation and testing of the proposed design has been done in Java. The analysis showed that <span style=\"font-style: italic;\">Decorator <\/span>has several drawbacks if it is applied in the classical way. The further analysis leaded to the <span style=\"font-style: italic;\">MixDecorator<\/span> pattern.<\/p>\n<p>The pattern has been used in order to allow the creation of new collections based on dynamic composition of the features that characterize the corresponding data structures. In this way we may add or remove features dynamically.<\/p>\n<p>The fact that only linear combinations of features are allowed could be seen as a disadvantage, but since the classical version of <span style=\"font-style: italic;\">Decorator<\/span> has been replaced with <span style=\"font-style: italic;\">MixDecorator <\/span>this disadvantage is hidden: <span style=\"font-style: italic; text-decoration: underline;\">the features with changed interface are visible even if they are not added as a final decoration<\/span>.<\/p>\n<p>Here the advantage of using the presented pattern is very clear. Without this pattern the framework design and usage would have been much more difficult.<\/p>\n<h2>Refferences<\/h2>\n<p>[1] Virginia Niculescu. MixDecorator: An Enhanced Version of the Decorator Pattern. In Proceedings 20th European Conference on Pattern Languages of Programs (EuroPLoP&#8217;2015) Kloster Irsee, Germany 8-12 July 2015 (<a href=\"Articole\/MixDecorator-initial.pdf\" target=\"_blank\" rel=\"noopener\">link<\/a>)<\/p>\n<p>[2] V. Niculescu, D. Lupsa, A Decorator Based Design for Collections, Proceedings of KEPT 2013: The Fourth International Conference On Knowledge Engineering, Principles and Techniques (June 2013) Studia Universitatis &#8220;Babes-Bolyai&#8221;, Informatica, Volume LVIII, Number 3 (Sept. 2013). pp. 54-64 (<a href=\"http:\/\/www.cs.ubbcluj.ro\/%7Estudia-i\/2013-3\/303-29.pdf\" target=\"_blank\" rel=\"noopener\">.pdf<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>TOC Decorator MixDecorator &#8211; Definition MixDecorator &#8211; Extensions MixDecorator &#8211; Implementation MixDecorator &#8211; Advantages MixDecorator is enhanced version of the classical Decorator pattern defined in Gang of Four book. The classical Decorator pattern offers a solution to extend the functionality of an object in order to modify its behavior. Still, when we want to add\u2026 <span class=\"read-more\"><a href=\"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/mixdecorator-an-enhaced-version-of-the-decorator-pattern\/\">Read More &raquo;<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_links_to":"","_links_to_target":""},"_links":{"self":[{"href":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-json\/wp\/v2\/pages\/78"}],"collection":[{"href":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-json\/wp\/v2\/comments?post=78"}],"version-history":[{"count":19,"href":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-json\/wp\/v2\/pages\/78\/revisions"}],"predecessor-version":[{"id":223,"href":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-json\/wp\/v2\/pages\/78\/revisions\/223"}],"wp:attachment":[{"href":"https:\/\/www.cs.ubbcluj.ro\/~vniculescu\/wp-json\/wp\/v2\/media?parent=78"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}