 Hello everyone, my name is Kevin. I'm Vietnamese. I just come to Singapore about a month ago and got a job for two weeks ago. Can you hear me? Hello, first thing I want to say, thank you to Vincent for introducing me to Sam. So I get a pleasure because of him and I can stand there to talk with you guys. Thank you. Ok, so today I want to share my experience in working with the decorator button in Ruby. The three points I want to talk first is why we use decorator. Secondly, how and the third one is when we shoot you. So I believe the business logic is the root of the ugly code. Because in the beginning your class will be very simple and easy to read with a very few minimum published interface. So easy to write and easy to test. Time by time the business logic comes and you must add a lot of business logic into your code. And it looks heavy and mess up everything. So we already support us for some convention to have anyone call to soften the methods. But there is another way to enhance the object easily with our method. Everything in your class is the decorator button. First I want to give you guys an example of how we mess up the class with the business logic. This is a hero in the game Dota 2. Actually you guys know her. This hero has four skills here. First hero, Girls, Racer, Aura and Markman Shift. And from just four basic skills here without the support. They can generate some kind of attack like the normal attack without the skill. First hero attack, Girls and they can combine the normal attack with the Racer, Aura and something more. Maybe three skills together. And how we implement these kind of attack in our class is two way. First, you boost every type attack to a method like this. So there are standard methods. The maximum method will be high power n minus 1, the total success of the fourth skill. Another way is you use the subclass. So every combining of skills you create a new class. So in this case we can use the same methods for every class. So plan like attack. You also create a new object and call attack. But it's still a lot of things you must do. Because it's too many methods or too many subclass. So it's very hard for you to remember exactly the methods or the class name. And like if you want to change the skill, how many things you need to change to fix the new code, the new skill. Or you want to add a new skill. So you need to create a lot of functions or a lot of subclass to combine everything. So with the decorator button. This is the original class. We just have a method named attack. And we create an attack decorator with a method. Notice the same method name. And then we create some decorator that inherits the original attack decorator. And then we implement the attack in a different way. Let's notify the hero object here. We call the attack. This came from the original class called this one. So how do we use it? We can initialize a hero contrast here. And we call the attack method. Or we want the contrast. Hero creates a cross error attack. So we can call cross error decorator new with the hero object. But we bust it over there. And we call attack. Or we want to combine three types of attack together. So we call mic and chip decorator of new just hit cross error. We see the object here. We see also the decorator. So for the general decorator uses. Like this. First decorator new, second decorator of new. Third decorator of new. Fourth decorator of new. And finally the object. And maybe more. So in this case, you use the same method for every decorator. It's good because you don't need to write a loss. And the user, that's you, your decorator. Can save time to remember every method. And you can keep the original class. Simple, very simple, clean and beautiful. Easy to test. And easy to add new feature. Like create a new decorator for the new skill of attack. But you need to keep the interface very simple. Because it is a little bit complicated. So every order decorator will be passed a loss of parameters. So it's not good. And because you pass the object to a loss of decorator like that. So maybe this will be a lot of memory that you are using yet. So it will not be a little bit super performant. And another thing is it's not easy to test it. It's some auto-developer using writing some code like this. So we want to work every object here for processing for writing aspect. So last thing is when we're using it. First is when the class have similar methods. Like the Herald class for the first symbol I give you. And second is for Revolve data. So because we use the same result data for every Revolve. But we must create a different type of Revolve. For like self or HR finance. But it's very similarly so you can use the decorator. Another thing is the dropout of the game rest. I think most of you know it already. And because of the concept of the decorator. If that you decorate a methods you can be happier. So it's not just the class decorator. It's just not class but also the methods. Here is some like methods and methods change. But support by activity support. And then it is in FTC protocol model. It's also using the decorator. Ok so this is my reference. Thank you for listening. Any question? Ok well if you think of any later. We will be here of course. Thanks again.