 My name is Eder, I'm a senior software engineer by Red Hat from Brazil. I'm a leader of UberFire, and UberFire is built to build the rules in ABPM, the product BMS and BMS, and I'm here to talk to you not about my products, but about how to build design patterns in Java with functional programming. The first one I will go straight ahead, and that's one of my passions. Maybe the phones will look weird because I just changed my laptop right now. The first one is to be a strategy. What your strategy should look like if I'm moving from an object software to a functional programming. Usually a strategy is to define a family of algorithms, encapsulate each one, and make them interchangeable. I love the definition, but I prefer to do that and to learn that by example. So let's see and show an example. In our example, you have a shopping cart, and this shopping cart has a lot of items. Here I have two items, item one, item two to my shopping cart, and I have to select the algorithm through the payment. I have to select if there is a credit or debit. Here I'm passing as a parameter for the method of pay, but the code will start to look weird because I have two types of payments, credit and money, and then I have to do everything with an if selector, if, else, if, if, else, if. It looks really good for now, but the issue we will start when I have to add more payment types for that class. I will start to have a lot of else ifs, and probably every buyer see that kind of code that creates a big chain of if, else, if, and else, if, and my code becomes a mess. Doing that is good, but the problem is that we violate with that the single response principle. Why? When you have a payment, we have to change the payment method. We have to add something in the payment method. My class shopping cart uses it to work very well, but as soon as I add a payment, I have to remember and to add a new else if there. That is really bad for the code, and really bad for the clean code. It's not a clean code as well. There is a solution in object-oriented programming with the strategy pattern and how you do in that presentation. You take the original patterns from the object-oriented programming and move them to be better with functional. But how that strategy pattern looks in the object-oriented code. I create an interface payment and just a method pay that receives the amount, and then I create a lot of implementations that each implementation has the behavior of my payment. A credit card has an implementation that's just a demo to fit in the slide, and my money has another implementation. That is really good because when I do that, I just change the payment method instead of receiving a new and making a lot of if, else, if, else, if, else, I can have an implementation of the class and just call the implementation. That is really good why the strategy pattern, because with the single responsible pattern when I add a new payment method, I don't have to change my shopping card. But in the end, for instance, if I create a new type, like debit card, I just have to add implementation. That is good, and we live well in that moment. But the bad part of that is that as my system goes on, I will start to have a lot of that small classes, and I have to build a type system in order to make that strategy. And sometimes that's making us really hard to justify the use of the pattern, because it's a clear trade-off in order to have the ability and flexibility to add payment. In a dynamic way, you don't have to change the shopping card. I have to create a new class and add a death class. But that things could be better. After Java 8, we have a functional support. I love functional programming. I'm a kind of functional programming expert in Brazil. And how can you write this pattern better in a functional way using the functional programming? How can things get me better? Let's present the interface consumer. In default, functional interface in Java, what the consumer does is receive an object and do some processing in the death and return void. I receive some object, do some processing, and in the end, return void. We can use that class in our payment. Instead of having a payment class that has the method to pay, you have to create the interface and implement it. You can use the consumer interface, and the consumer have the method accept. The accept receive object and return void. So it's the same way that we are doing our payment method in object-oriented, but without having to create anything, because it's a default Java interface. Using that, we can use the same way that the strategy from the object-oriented programmer. You can pass a lambda expressions. Instead of having to create the whole hierarchy that you use to have object-oriented programming, you can pass lambda expressions, use the consumer, and just use the accept method. So you don't have to clear and don't have to create a whole type of hierarchy in order to have the strategy pattern and you have the benefits. My question is, if you work, probably everybody works with real production case. Your methods doesn't look like one line, never. You have to make that method bigger. One way to do that, you extract that method to a static class. You have a class and some static methods, and then you can have other great features of functional programming. You can have method reference and pass the method of reference of the class. So it's really more cleaner. And if sometimes your method of credit becomes bigger, you can extract that for other class and consume. So that one, sorry for my type. I have to change my notebook and that's why my phones look weird. That's the strategy pattern that function. I have the same benefits of having an object-oriented pattern, but in a cleaner way, you don't have to create the type hierarchy. We just have to put your consumer interface and use that consumer, okay? The next one is the decorator. The decorator helps us to attach additional responsibilities to objects in the dynamic way. Decorates provide a flexible alternative to subclassing for extended functionality. I don't know if everybody agrees with me, but I have, when I was a junior developer, I have a kind of trauma with decorator patterns. Because my first contact with Java was with that. When I have to write a file, I have to, even doesn't know well object-oriented programming and I try to open a file and write a file in Java. I have this chain of constructor and I don't know what's that. But in the end, decorator is really good and let's see an example of how you can use a decorator. I have an item and this item have a lot of extras, for instance. I can have shipping, taxes and packing. If we're not using a pattern, probably as these things is optional, you have two options without the pattern. Or you create a lot of subclasses, for instance, item with international shipping and taxes and your code will become a mess. Because you have to create a lot of types. Or you have a lot of booleans that become a big, if else, if else, if else chain, it becomes hard to test and debug. When you have a special class and you have a lot of extras, that's the point that you can use a decorator pattern. Let's see how can do that. For instance, in our class, let's see how can do it in an object oriented way. We have, again, another interface, this interface that has the getPrice method. And I have an item and a book. A book's implement an item and have getPrice method. Just implementation of my interface. That's the class that will be decorated. Then, I put the item extras, that's the trick for to build a decorator and it's an abstract class that also implements item and have the getPrice method. See that getPrice is an item that are received in the constructor for that class. I pass a book, for instance, for that decorator and then getPrice of the book. When I need to decorate that, what I do? I extends eating extra class and add my behavior that would like to change. For instance, here, I do like to take the price of the book and add five. Other example, if I want to have gift packing for each book or every decorator, I add 15 to the super get price. It's important to pay attention that this eating extras is also an item. I think extras is also an item. So you can combine this decorator and change them together. Let's see how we can do that in a practice. I create a book, the price is 10. When I decorate that book, international delivery, the price become 15. If I do further than that, I add also gift packing for international delivery and can I have the chain of 13? I have the international delivery and gift packing. If I want to put more behavior, I create that chain. But also, again, I have to pay the trade off because I have to create this pattern to solve my problem. I have to create a type again. Sometimes it's good to create a type and sometimes doesn't. And when you are using object-oriented patterns in just an object-oriented code, you have to pay this trade off even when you don't need that. But with function, I can use functional programming to do that. I create a function and that function gets an integer and returns an integer. For instance, take a value and return a value plus 15. And I can use that default function from Java to have the same behavior of the decorator. When I do the apply for a price, I can add 15 for that method. And the same thing that we have with decorators in object-oriented programming. Then I can create other functions and apply again and have integer taxes. But you can go even better with functional programming because we have a method. It's an then method. I can combine functions and constructs. That's one function that have the value of the both functions combined. Then I can put all that functions together and create a chain and have the same behavior that I have with the decorator from the object-oriented programming. So when I create my new item, I have a set item extras or pass this constructor a chain of functions. And that chain of functions can be combined and applied to that price. So I add dynamic responsibility to my decorator and in order to create a decorator pattern. It's good because I can have the same benefits of doing everything that I used to do with a decorator in object-oriented programming without having to create the type class. So it's a good example of how to use. But again, if you are thinking, my functions need to be reused. I would like to build bigger functions. I can again do the same and extract classes for that function. See, it's the same signature. It's a function that receives an integer and returns an integer. So I put in separate class and then I can pass the decorator class from my item as a parameter constructor. So with functional programming, I hope two patterns you are seeing with me, you can write again and revisit all the design patterns and can write better and clean code using the default class. The next one is a template. The template has a big definition from the Goff book, but I always like to see examples. When I use a template, when I look at a method, the method does a lot of things that I already want to do, but I want to change one line in the method. I have to change a little line somewhere and reuse that method. Let's see how can we read that in object-oriented programming. I have to create an abstract class. See, the process method is the method that I would like to use again. But I have to change something in the beginning before the processing and after the processing, I would like to add some behaviors. In order to do that, I have to transfer my class for abstract class. So again, I'm creating a type hierarchy for that just to follow the pattern. Then I have to have two abstract methods to hook my new code on that. Then, when I want to decorate that class, for instance, VIP Bank and Extended Banking, I add the code that will be called before and the code for the line bank that will be called after. So I have to create that type hierarchy. I can do really better with functional programming again, for instance. I use the same consumer API that we see two patterns before and use that same consumer API to apply for that object. So again, I have the same template pattern but write really better with functional programming. The next one is the observer. The observer is when you have to create a relationship between the objects in a decoupled way. It will be weird because I have to change the fonts. But for instance, I have an exchange rate server. This exchange rate, you can register for that. You can publish new exchanges and you want to decouple all the consumers for that. The consumers will receive notifications each time that a new exchange rate was published. And I want to do that in a decoupled way. By the decoupled way, I mean the banks doesn't want to know about the exchange rate and the exchange rate server doesn't want to know who is connected to that. To do that in object-oriented programming, I create two interfaces, an object, a subject and an observer. The subject, you have the ability to register observers. And the observer is a method that will be called by the subject to notify the new changes. For instance, a bank is an observer and has a notify implementation for each exchange rate. And the investor is an observer that also has a notify method. Our observer, the subject, is an exchange rate server that implements a subject. And you can register observers to that and each time, each new exchange rate, it calls all the observers that was registered. How can I use that? For instance, I create a bank, I create an investor and create an exchange server. I register the observers and when I call a new exchange rate, it propagates the call for observers. But the observer has only one functional method. For sure, we can use that in a functional way. You can write that again, it's just an implementation that has only one method. That even is not a real object because I don't have state, I don't have anything, it's just a method that I have to create to respect the pattern. How can I do that with functional programming? I can create lambdas and register the observers in a dynamic way. I can create lambdas and that lambdas can be expected for other classes if it was big. But if it doesn't, I can hook my web servers, for instance, a micro-server or something and make a call in the register. So again, I can have the same behavior of the observer without having to create the type class. The last one is not a real pattern. It's a technique from functional programming that can be really useful for Java developers, but that not everybody knows that the technique is curring. What is curring? Curring is really good when we want to build functions through partial evaluation of other functions. But what that means? Again, you are in a functional programming talk, I will show you some mathematics, but just to have the example, not too much. I have a function fxy, it's just x divided by y divided by x. I would like to apply two and three for that function. First, I will apply two, f2y equals y divided by two, and now you call that function by g. So gy equals f2y equals y2. When I apply three, do you see, I will replace everything, but for g points of perspective, it just want to call. Because with curring, I can kind of eat some parameters and have some parameters by default. But why that is important for us? For instance, one common thing is conversion to a threshold to a finite height. And for conversion, it involves a conversion factor and some quays and some quays, a just factor, for instance, to convert from Celsius to a finite height, I have a conversion factor of 9 divided by 5 and the just factor of 32. Let's write that, but I will write that in a kind of different way. You see in some slides why I do that. I will write a conversion function that will be received, the number that I would like to convert, the conversion factor and the baseline. If you want to add something, it will become x times f plus b. When I use that to convert Celsius to a finite height, I pass 9 divided by 5 and 32 and the result will be 69, OK? Then, how can I use curring programming to do that, curring functions in order to make that better? I will create, instead of my converter, my regular converter, I will create a fabric of functions. W-Nerd operator is just a function that receives a double. You do that to avoid casting and to avoid that kind of stuff. But instead of having three parameters and do x-versions, the conversion factor plus my number plus the baseline, I will create a function that will receive a double and then multiply by f, its conversion factor, plus my baseline. That is curring. I'm receiving two parameters and you see I put that parameter as a full and create a new one. Then, I can generate my functions factory, which, for example, is our best way to do that. I will create a function, see my current converter, I will pass SF 9 divided by 5 and 32 and that will generate a new function that when I receive a double, I will take that double and multiply by f and plus be the conversion factor. So, I generate a new function by a partial apply and that is curring. But why that's useful for us? We can use the same curring function to create another converters because it's a genetic way for mathematics, that converter. I can convert for kilometers two miles, for instance, passing 0.62 for each kilometer and multiply for 6.1 and we don't have baselines, so it will become zero. So, I did the same function generator using curring to create and to eat that two parameters and apply them as a full and generate a different function. But I can go further than that. In Brazil, I used it to work a lot with exchange banks and you can use your same converter, your same curring technique. That's why curring is really good because you can map traditional mathematical things that are distributed in your code and make them as fabric generator. Then, I create the same converter to convert Brazilian real to dollar and the baseline is zero and create a function that each time that I put a Brazilian real converts to dollar. Or I can even go further because I can convert because in order to make by euros in Brazil, you have to buy dollar first and then convert for dollars for euros. As I am building functions, I can leverage in all the arsenal of functional programming to combine them in a functional way, okay? I have some minutes to talk here more for some questions. That was a big talk for me. Sorry for my size, I will fix that. It's a big talk that I present on Sunday. It slides on my Twitter. It's like 10 or 12 patterns the same way. I hope you guys have enjoyed that. Thank you.