The following is a series of posts about "functional programming in Java" which is the result of my understanding by reading the book "

1. Why functional programming?

2. Functional programming in Java 8

3. Java 8 - Using Functions as Values

4. Java 8 - Persistent data structure

**Java 8 in Action: Lambdas, Streams, and Functional-style Programming, by Alan Mycroft and Mario Fusco**".1. Why functional programming?

2. Functional programming in Java 8

3. Java 8 - Using Functions as Values

4. Java 8 - Persistent data structure

In general, the phrase

*"functional-style programming"*means the behavior of functions should be like that of mathematical-style functions - no side effects.

In programmers' point of views, functions may be used like other values:

*passed as arguments, returned as result, and stored in data structures*. That means we can use the :: operator to create a method reference, and lambda expressions to directly express

**. For example:**

*function values*//method reference Function<String, Integer> strToInt = Integer::parseInt; //lambda expression Comparator<Integer> comparator = (a, b) -> a.compareTo(b);

There are two practical techniques to apply in our codebase.

## Higher-order functions

For example:Comparator<Apple> c = Comparator.comparing(Apple::getWeight);

- Take one or more functions as parameter
- Return a function as result

*If so, for what?*

*Good question! To*

*compose functions to create a pipeline of operations. It's close to declarative programming.*

## Currying

**f**of two arguments (x and y, say) is seen instead as a function

**g**of one argument that returns a function also one argument. The value returned by the latter function is the same as the value of the original function, that is, f(x,y) = (g(x))(y).

Brain overload! For example, you want to convert Celsius to Fahrenheit, the formula is

*f(x) = x *9/5 + 32*. Not only this case but we can see the basic pattern of all unit conversion is as follow:

static double converter(double x, double f, double b) { return x * f + b; }This method is a bit too general. Obviously, we can use it to apply for all unit conversion but it would be tedious and you might accidentally mistyped them. There is an better approach:

static DoubleUnaryOperator curriedConverter(double f, double b){ return (double x) -> x * f + b; }Instead of passing all the arguments x, f and b all at once to the converter method, you only ask for the arguments f and b and return another function, which given an argument

*x*return

*x*f + b*.

Why is it the better approach? This enables you to reuse the convention logic and create different functions with different convention factors:

DoubleUnaryOperator convertCtoF = curriedConverter(9.0/5, 32); DoubleUnaryOperator convertUSDtoGBP = curriedConverter(0.6, 0); DoubleUnaryOperator convertKmtoMi = curriedConverter(0.6214, 0);Instead of three different method for each conversion factor:

static double convertCtoF(double x, double f, double b) { return x * f + b; } static double convertUSDtoGBP(double x, double f, double b) { return x * f + b; } static double convertUSDtoGBP(double x, double f, double b) { return x * f + b; }Foo:

*If so, for what?*

Bar:

*It helps you modularize functions and reuse code!*

**Reference**

**[1]. Alan Mycroft**and

**Mario Fusco**, Java 8 in Action: Lambdas, Streams, and Functional-style Programming. Part 4. Beyond Java 8.

yeah, great post abou java

ReplyDeleteCan you visit my ebook đấu phá thương khung

Thanks for sharing this good blog.It's amazing blog

ReplyDeleteJava Online Training Hyderabad