After the introduction posted last week, hope it gave out a rough concept of how Lambda look like and what can it do for us. In this article, we would extends further by using Comparator example to explore more possible way of writing lambda expression? Cuz for me personally, it take some time to transit both mindset and coding style to adopt functional programming approach on a mature OOP language like Java. Hence following example show varies way of how Comparator can be implement in Lambda era.
The purpose of this piece of code is sort out the Coffee ArrayList by it’s price. And in here we achieved this by implement Comparator interface, as some you guys may heard it before.It is kind of popular one when come to object sorting-ish thing on Java side. Just like overloading on C++.
– Old way (Implement interface)
Which is the most popular way and it’s just work, create an object, implement it with comparator interface, then put the custom logic under compare(). In this case would be CoffeeComparator which is listed below.
Then by the time Array list.sort() got called. It would run mergesort underneath by implement the compare() method specified earlier. Easy-peasy. This approach work well, Dev used it with satisfaction. Since the nature of seperate Object file (.java). It
can be reused easily.
But what happen if the use-case change. Let’s say now the comparison criteria now become have much more type, may be need to compare by the Brand instead of the prices? The ratio of milk? and such and such and most importantly some of them are disposable which mean only implemented on really limited scope and often one time used only . In this case a new .java Comaprator class need to be created for a new criteria and soon the growth of Comparator class would drive you crazy. Let say you having like a 50-ish Comparator class under the same package?
You may then argue like, oh Comparator interface can be implemented on demand, Which would look like the following:
But still there too much un-necessary thing in above snapshot, clearly we are not satisfied with that.
Here is how Lambda expression come into kick. Turn out Comparator adopted Functional programming from J2SE8 onward and so now we are easily turn those Comparator into Lambda expression just like Runnable [URL] we mentioned last week. By giving the promise that it have a limited scope and disposable.
In this way when code evoked, new CoffeeComparator would be created and used. No new .java file is created in this case. A bit cleaner?
The main catch here by ArrayList.sort() only have one signature, which take a Comparator as an input. What it mean is the only possible input can only be Comparator. Then why bother to specify it as Comparator?
Let have a look at Example:3. We dun specify a comparator, instead we put the exact logic of compare method () on it.
Which is how to compare order between two Coffee object. In this way, Javac would smart enough to understand. Oh it’s having the same signature as Comparator with method override by type .
In this way, several lines saved and less boilerplate code is need to specify that Javac would understand of its own already.
– Lambda with Comparator
But you may still not satisfied with it. There should have some one-liner approach for it right????
You are right, One-liner solution do exist. Which can be done by calling Comparator.comparing method call() with member type. That’s all you need, to tell Comparator what member object used for comparation, in this case is Coffee::getPrice. The whole would just work. Do note that if the comparation intended to use involve more check and such, then it’s easier to handle it separator or actually is totally fine for do it via the old way.
Hope above example would let gain more insight of how lambda can be used in daily dev cycle.
Hiu's code yard 