Decorator

Motivational example GUI Toolkit

Motivational Example - GUI Toolkit Several GUI elements, several decor options slider - top / bottom frame (different widths) We focus only on TextView 3

Motivational Example - GUI Toolkit The GUI Toolkit contains the TextView component plain text display We want to customize this component "decorate" add slider add a frame etc. It would be useful: also have the original TextView available without decorations combine elemets slider + frame add some properties multiple times double frame add / remove specific properties at runtime "Layered structure" Maybe they can throw layers => slider inside or outside the frame 4

Motivational Example - GUI Toolkit First solution attempt: "superclass" contains flags for all possible decorations the rendering method controls the presence of individual decorations class TextView { private bool isBordered; // Is TextView bordered? private int borderWidth; // Used only by bordered TextViews. private bool isScrollable; // Is TextView scrollable? private int scrollBarPosition; // Used only by scrollable TextViews. // ... public void Draw() /* Main drawing logic here. */ if (isBordered) /* Border drawing logic here. */ } if (isScrollable) /* Scrollbar drawing logic here. */ 5

Motivational Example - GUI Toolkit First solution attempt: "superclass" we can add / remove properties at runtime ☺ we do not have to decorate at all ☺ no need to distinguish between ordinary and decorated instances ☺ we can combine the properties ☺ we can not use one property multiple times ☹ the instance knows it is decorated ☹ highly inflexible solution ☹ ☹ ☹ non-expandable without TextView ☹ We need to modify each class individually ☹ ☹ TextView Button Label Grid Panel ... ----- Meeting Notes (3/22/14 23:13) ----- Je to ošklivé The problem of multiple classes can be solved by a common ancestor yet problematic Problem - horizontal and vertical sliders code duplication Impossibility to choose decoration order 2. Proposal: to use some form of inheritance 6

Motivational Example - GUI Toolkit Second solution attempt: inheritance base class - TextView derived - BorderedTextView, ScrollableTextView, BorderedScrollableTextView class TextView { // ... fields and other necessary textview logic public virtual void Draw() { /*...*/ } } class BorderedTextView : TextView { // ... border-specific data and logic public override void Draw() { /*...*/ } class ScrollableTextView : TextView { // ... scrolling-specific data and logic class BorderedScrollableTextView : ScrollableTextView { // ... border-specific data and logic, probably copied from BorderedTextView 7

Motivational Example - GUI Toolkit Second solution attempt: inheritance static Can not change instance properties at runtime ☹ for each combination of properties, you need to create a new class We still can not arbitrarily choose the combination / order ☹ ☹ BorderedScrollableBorderedTextView ... ☹ leads to explosion of classes (n property → 2n classes) ☹ ☹ ☹ significantly increases the complexity of the system ☹ ☹ Changing properties at runtime means creating a new object, copying data and replacing it What about references to the original instance? Can I fix them all? Multiple inheritance in C ++ COMMON PREDICE TextView !!! name overlay? can not it get better? Return to the original layered idea 8

Motivational Example - GUI Toolkit 3. Return to the original idea of ​​the layers Delegation of frame / slider rendering to another object Idea: Separate individual decorations from the original object Framed textview has two parts: textview and frame The frame will hold a reference to the textview it decorates The new object will only worry about rendering the frame / slider, rendering the textview itself to the textview itself 9

Motivational Example - GUI Toolkit Third solution: Decorator Common (abstract) ancestor - def. drawing interface A specific visual component Reference to the decorated object Delegation rendering to a decorated object Abstract decorator Specific decorators except delegations implement their own rendering Specific Decorator 10

Motivational Example - GUI Toolkit Third solution Decorator public interface IVisualComponent { void Draw(); } class TextView : IVisualComponent public override void Draw() {  // draw window // ... abstract class Decorator : IVisualComponent  protected IVisualComponent vc;  // decorated component public Decorator(IVisualComponent vc) { this.vc = vc; public virtual void Draw() { vc.draw();           //delegation class ScrollDecorator : Decorator { public ScrollDecorator(IVisualComponent vc) : base(vc) { } public override void Draw()  { base.Draw();     // draw component DrawScrollBar(); } private void DrawScrollBar() { /*...*/ } // scrolling logic implementation // ... class BorderDecorator : Decorator { public BorderDecorator(IVisualComponent vc) drawScrollBar(); private void DrawBorder() { /*...*/ } 11

Motivational Example - GUI Toolkit Third solution: Decorator decorators add individual features (decorations) we can add / remove properties at runtime ☺ we also have a common TextView ☺ decorations are independent of each other ☺ can be arbitrarily combined ☺ they can be used several times ☺ it's transparent ☺ from the client's point of view, there is no difference between ordinary and Decorated TextView TextView about decorations does not know at all VisualComponent licenseTextView = new BorderDecorator( new ScrollDecorator( new TextView())); // somewhere else: licenseTextView.Draw(); To get properties, we need interface support! 12

std::reverse_iterator Motivational example std::reverse_iterator

Motivational example – std::reverse_iterator Example of minimalistic implementation template <typename Iter> class reverse_iterator : public std::iterator< typename Iter::iterator_category, typename Iter::value_type, typename Iter::difference_type, typename Iter::pointer, typename Iter::reference> { private: Iter current; // decorated iterator public: explicit reverse_iterator(Iter&& p) : current{std::forward<Iter>(p)} {} void operator=(const reverse_iterator& other) { current = other.current; } typename Iter::reference operator*() const { auto tmp = current; return *--tmp; reverse_iterator& operator++() { --current; return *this; bool operator!=(const reverse_iterator& other) const { return current != other.current; }; template <typename Iter> typename reverse_iterator<Iter> make_reverse(Iter&& i) { return reverse_iterator<Iter>{std::forward<Iter>(i)}; } void print_elements(Iter begin, Iter end) { for (; begin != end; ++begin) std::cout << *begin << " "; int main(int argc, char* argv[]) { std::vector<int> v = { 1,2,3,4,5,6,7,8,9,10 }; print_elements( make_reverse(v.end()), make_reverse(v.begin())); std::cout << std::endl; 14

Decorator - Summary Structural pattern Expands objects for additional behavior Extends specific objects, not classes expands the object dynamically, ie, at runtime Prefers the composition of objects before inheritance Delegation calls to the decorated object + custom functionality own added behavior may be before and after the delegated call 15

Decorator - structure and participants Component - def. interface for objects that can be dynamically expanded ConcreteComponent - def. an object that can be dynamically expanded Decorator - an abstract front of all decorators contains a refinement to the object it decorates delegates all the calls to the decorated object ConcreteDecorator - Adds additional behavior to a component 16

Decorator - implementation Usage typically using constructors chaining: The Decoder Interface must be the same as the Decorated Object Interface inheritance from a common ancestor or implementation of a common interface An abstract decorator can be omitted assuming we only need to add a single extension often when we need to expand the existing code delegation to the component is then done directly in this single decorator The Common Component should remain lightweight interface definition, not data storage otherwise the decorators will be too heavy Component c = new ConcreteDecoratorA( new ConcreteDecoratorB( new ConcreteComponent(...))); c.Operation(); 17

Decorator - advantages and disadvantages greater flexibility for adding functionality than static inheritance properties can be added / removed at runtime multiple uses of the same decoration transparency there is no need to predict all the needs of the client simple incremental addition of functionality Disadvantages the component and its decorated version are not identical the decorator acts as a transparent encapsulation when using decorators do not rely on the identity of objects! many similar (small) objects potentially worse orientation in the code long strings of decorators can impact on performance 18

Real examples of using Decorator Graphical toolkits Java Swing System.Windows.Controls Reading input, writing output System.IO.Stream java.io Component ConcreteComponent Decorator DataInputStream dis = new DataInputStream( new GzipInputStream( new BufferedInputStream( new FileInputStream("file.gz")))); dis.Read(...); ConcreteDecorator 19

Related Patterns Adapter Decorator changes only the behavior of the object, not its interface The adapter will give the object a completely new interface Composite Decorator can be technically seen as a simplified Composite with a single component Decorator adds additional behavior is not intended to aggregate objects Strategy Decorator allows you to modify/customize the object essentially covers an object and changes its behavior while Strategy allows you to change the "guts" of the object a component in Strategy knows about possible extensions, not as Decorator: 20