"lambda" entries
Blocks in Ruby
A fundamental Ruby idiom explained.
When we talk about blocks in Ruby, we’re not usually talking about code blocks — or blocks of statements — as we might with other languages. We’re talking about a special syntax in Ruby, and one of its idioms. I’ll be discussing blocks in this article, plus a little about procs and lambdas.
Ruby’s blocks are always associated with methods, which are sets of recallable procedures. Blocks can’t get along very well by themselves. They are dependent on methods, which normally feed data to them. Without that data, a block can’t do anything useful. It needs a parent to look after it.
Blocks are anonymous and are sometimes referred to as nameless functions. Blocks are like methods within another method that grab data from an enclosing method. If all this is unfamiliar to you, it may not make sense. Keep reading and I’ll do my best to clear things up for you.
4 things to make your Java 8 code more dynamic
Anytime is a good time to refactor your code.
Java 8 has a few new features which should help you write more dynamic code. Of course one of the big features was the addition of a lambda syntax. But what about some of the other features that were added? Here are a couple of things that I tell people to do in order to make their code more dynamic and more functional.
Java 8 streams API and parallelism
Leveraging intermediate and terminal operators to process large collections.
In the last post in this series, we learned about functional interfaces and lambdas. In particular, we looked at the ITrade functional interface, and filtered a collection of trades to generate a specific value. Prior to the feature updates made available in Java 8, running bulky operations on collections at the same time was ineffective and often cumbersome. They were restricted from performing efficient parallel processing due to the inherent explicit iteration that was being used. There was no easy way of splitting a collection to apply a piece of functionality on individual elements that then ran on multi-core machine architectures — that is, until the addition of Java 8’s Streams API.
Using the command pattern with lambda expressions
Reduce boilerplate and make the intent of your code more obvious.
As Java developers we’re all familiar with the concept of Design Patterns. These are codified template solutions to problems that we may encounter when developing. We’re probably also familiar with being told by our functional programming brethren that design patterns are just “missing” language features. So the question now arises, with the introduction of lambda expressions in Java 8 and a more functional style of programming, how do design patterns change? In this article we’ll be looking at the command pattern.
A command object is an object that encapsulates all the information required to call another method later. The command pattern is a way of using this object in order to write generic code that sequences and executes methods based on runtime decisions.
There are four classes that take part in the command pattern:
- Receiver – Performs the actual work
- Command – Encapsulates all the information required to call the receiver
- Invoker – Controls the sequencing and execution of one or more commands
- Client – Creates concrete command instances
Let’s look at a concrete example of the command pattern and see how it improves with lambda expressions. Read more…
Unit Testing Java 8 Lambda Expressions and Streams
Two approaches to testing lambdafied code.
Over the past 18 months or so I’ve been talking to a lot of people about lambda expressions in Java 8. This isn’t that unusual when you’ve written a book on Java 8 and also run a training course on the topic! One of the questions I often get asked by people is how do lambda expressions alter how they test code? It’s an increasingly pertinent question in a world where more and more people have some kind of automated unit or regression test suite that runs over their project and when many people do Test Driven Development. Let’s explore some of the problems you may encounter when testing code that uses lambdas and streams and how to solve them.
Usually, when writing a unit test you call a method in your test code that gets called in your application. Given some inputs and possibly test doubles, you call these methods to test a certain behavior happening and then specify the changes you expect to result from this behavior.
Lambda expressions pose a slightly different challenge when unit testing code. Because they don’t have a name, it’s impossible to directly call them in your test code. You could choose to copy the body of the lambda expression into your test and then test that copy, but this approach has the unfortunate side effect of not actually testing the behavior of your implementation. If you change the implementation code, your test will still pass even though the implementation is performing a different task.
Java 8 functional interfaces
Getting to know various out-of-the-box functions such as Consumer, Predicate, Supplier
In the first part of this series, we learned that lambdas are a type of functional interface – an interface with a single abstract method. The Java API has many one-method interfaces such as Runnable, Callable, Comparator, ActionListener and others. They can be implemented and instantiated using anonymous class syntax. For example, take the ITrade functional interface. It has only one abstract method that takes a Trade object and returns a boolean value – perhaps checking the status of the trade or validating the order or some other condition.
@FunctionalInterface
public interface ITrade {
public boolean check(Trade t);
}In order to satisfy our requirement of checking for new trades, we could create a lambda expression, using the above functional interface, as shown here:
ITrade newTradeChecker = (Trade t) -> t.getStatus().equals("NEW");
// Or we could omit the input type setting:
ITrade newTradeChecker = (t) -> t.getStatus().equals("NEW");