>_Programming podcast with Minko Gechev

Episode #8 Decorator Pattern

Today you'll learn how at runtime, you can enhance the behavior or existing objects using the decorator pattern. In this episode, we'll discuss the advantages of decorators over inheritance and look at two examples from real-life - implementing a network communication protocol and enriching user interface components.

Today you'll learn how at runtime, you can enhance the behavior or existing objects using the decorator pattern.

In this episode, we'll discuss the advantages of decorators over inheritance and look at two examples from real-life - implementing a network communication protocol and enriching user interface components.


Episode 8 - Decorator Pattern

00:00:02 - 00:05:04

welcome to the programming podcast. Here you can learn about computers in the brief and accessible way I'm your host mean could get. Hello everyone today. In this rather short episode we are going to talk about the decorator potter so by decorator. I if you're used to javascript or python or any other language which provides a construct called decorator. We're not going to necessarily talk about us. We're going to talk about the design pattern decorator in general pattern it was described in the gang of four book of Erich Gamma and Company. So his craft this design pattern as a way to at additional pieces of functionality as any harassment for existing objects the decorator pattern is sometimes compares to composition versus. He Sheraton's because in both the decorator pattern and The par dime composition over heritage. We are using object instances and we're attaching some extra behavior to them. We're enhancing these objects instances without creating a complicated inheritance chain now in the sense. They're quite similar but the decorator pattern aims to preserve the exact same interface or enhanced. Little Bit as the object that we want to add extra functionality to all right before going. Kenya furhter wants to address something since recently. There is a huge controversy around object oriented programming since the functional programming which is like very old paradigm as well is getting trendier and trendier. In the modern web development alert people start seeing that object oriented programming his apartment which was mistakenly should forget about. That's really wrong. Even if it is not the ideal way to create software if we completely forget about the past at some point we're going to reinvent and second of all object oriented programming although it is far from ideal like any other paradigm. It is extremely useful in a lot of cases. Sometimes it is very convenient to model our domain with classes and objects and of course. We should be careful by making sure that we're not creating their own constructions. We are managing our mutable state properly and so on and so forth. Now when I'm talking about the decorator pattern I'm going to discuss it particularly in the object oriented approach but in the same time you can decorate a function as well especially in functional programming languages which have higher order functions. You can accept one functions and arguments to another and you can ask some extra behavior before and after dysfunction so this is a composition of functions but well in object oriented terms. We can call it decoration. Some extent I guess okay and they'll let us talk about different applications of the crater ZAMPA author the most traditional approach which was explained in the book of the gang of four. It is in user interface for example. If you have e textbooks with a lot of texts into you want to add a scroll bar you can just decorate this text books out the Scroll Bar and forget about later on if you want to out. Some additional enhancements such as. Let's say a border around was decorated already? We just crowbar textbooks. You can just create another decorator which adds a border later on. If you want to add a second border you want to have e UI which it with two borders you can just decorate the oars decorates traction and that's we can compose this way different decorators in Ritchie slightly. Different behavior now. How does decoration happen when you want to extend the behavior of an existing component of an existing class? Let's hear class button. What do you usually do is applying heretics right? You have a button right. After that. He extent this button with a sea border button if they think which has a border after that you may want to add a glowing effect. Let's say and you create one more class disinheritance chain and you have a glowing border button but after that you remember that you want to have just a glowing button so you may want to create another glass right which is called a glowing button and this way you have already three different abstractions. You have actually four. You have your original button. You have your border button your borger glowing button and you're glowing butter and this might not be nicer with the decorator pattern.

00:05:04 - 00:10:15

What you can do. Just find your primitive abstraction button. It is already there. You can create a borough which accepts an instance of A. Let's say you why we or something which happens to be implemented by the button and a border around. You Have Igloo Inc you. I wish it as well which is just another class which accepts e you. I wish it at this glowing effect around it. It is very important for the glowing. Ui widget and for the border. You I wish it for both of them to implement the Coen obstruction caught you eye widget. Because this way you'll be able to compose things around you'll be able to create a glowing button. Just by reading instance of the glowing and passing a bottom in its constructor and dates are on. You'll be able to take this and pass it to the constructor of the twitch it and this way you're going to have a border glowing button. This is an extremely convenient design partner in user interfaces. It can see you can use these very lightweight classes which later on you can compose and you'd more sophisticated solutions and you compose metron time. Which is fascinating. You don't have this explosion of different classes and these complicated inheritance chance so the decorator resent is a fascinating pattern to go. Actually this reminds me the first. The first time I heard about design Padre was longtime ago. That was maybe over ten years ago. I was first year in college and We were able to implement a new data. Structured absolutely nowadays directors class so our university professor wanted us to implement a billion array where we were keeping the individual boolean values instead of in a bully rain simplest. Plus where each individual invalid takes bite. He wanted us to implement this data structure by using individual bits. Because well the Valerie's just true or false and we can represent this with a single bit which is either zero one. We went through there and implemented actually implemented for us and we're just following along but we ended up having this strategy which he later referred to the property potter and design patterns. Well given also that he said this in English and we were in a Bulgarian University. We work quite confused so after two showed that we don't know design patterns. Are you said like Har? You like Ori- force hearing university how you don't know who designed partners are we're already our first year but that is a really excellent motivation for us to go ahead by the Patterns Book and Study Oldies Difference Call Slips in order to help us improve the software that who were building right. This happened to be an extremely essential Zampa other for me as well. A couple of months ago Corsair acquired a startup that I co-founded cold rammed calm and incentive in the system I use the decorator example a couple of times and given that I rewrote the product because of different requirements. A Few Times. I had to implement this design pattern properties five times or so now. I use this for something else I do and use it for user interface. I took advantage of that in order to build a network protocol for communication between the front and the back end in Ram dot com. We want to have a real time updates in a lot of different places. It was pretty much a traditional single page application where we had our framework on the front and we have a back end and we want to get updates between individuals students because education platform was the guy joints or whilst Stephen Jones. We want to get an E. We wanted to immediately notify the teacher. What would it was ending up implementing a web sockets three? So when you win. A new student joins we were sending push notifications to the guides. Wear to the students information. We ended up multiplexing. There's like we'll be placing a lot of different messages over this web sockets three and we ended up sending Mike some screen shots. We ended up sending some business messages. Like business details for example we implemented chat over this communication protocol. We were sending goes well some system messages and so on and so forth originally we just created the simple obstruction. I believe we call the channel or something on these lines this channel and just knew how to send and receive messages. We had an implementation of this channel obstruction. This channel was just an interface. We have a website channel which was accepting a call it which knows how to decode encode individual website messages which were in binary format because we were really aiming for high efficiency and very low bandwidth usage and from home.

00:10:15 - 00:13:08

We were just able to encode individual messages at the user was passing and right after that we were able to decode them and send them over to website extreme right so far so good but at some point we wanted to implement an abstraction which was able to sent a message and after receive response of this message brought we could have done was obviously implement actually inherited from swept socket message bus or however we call it and try. It's after implement this request response from genetic but imagine if we wanted to change the communication channel that we're using internally. We wanted to switch from websites to web. Rtc well in this case will have to implement yet another abstraction and who have to complicate our inheritance. Chang changed dramatically without actually adding value. Pretty much had to duplicate the functionaries that we had in our web sockets request response abstraction to our web RTC request response abstraction himself. So we're just create a requests pulse message channel or request Response Channel at remember. How exactly we call it. This channel was accepting a channel in its constructor and it will just adding this request response logic basically every message that we were sending. We were assigning to eat a UI android after that. The client on the other side was responding with a mass. Which with the exact same you. Id So we're keeping a hash with the messages that we sent and their corresponding hugh ideas. That was pretty much everything and when we receive a message which specific you I did. That was already in our map. We're just notifying the client that well. Here's here's the response that you were waiting for. That's where we used the creator and of course we use decorator on many other times where we want to attach some extra features to our. Ui Abstractions wants to talk about this design pattern not only because it is very essential indicate may look in it can may look your source code to more elegance and help you just kill just butte rich user interfaces or you'd reach back end systems by just composing. See what you already have. It is also very essential for the understanding of the aspect oriented programming. This is a paradigm that we're going to discuss sometime in the future. I hope you enjoyed this episode. I'm going to add links to the gang of four books together with Provia decorator example on the page associated with episodes. Thank you talk to you next time. Learn about the episodes. You can follow me on twitter at an get you. The list of horses and recordings is available at PODCAST DOT com. Get YOU DOT com. Thanks for listening.