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.
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…
You're using the web even when you don't think you are.
With the rise of native apps and the Internet of Things (IoT), you might think we’re leaving the web behind.
Other languages and approaches absolutely have their place, especially in the many environments where constraints matter more than connection, but the web core is everywhere: in your phone, your apps, the kiosks you find in stores and museums. It lurks invisibly on corporate networks helping databases and messaging systems communicate.
That enormous set of web-related possibilities includes more than a set of technologies, though. Tools and techniques are great, but applying them yields a richer set of sometimes happy and sometimes controversial conversations.
I’ll be exploring a core set of nine key themes over the next few months, but I’ve started with brief explanations below. These short tellings set the stage for deeper explorations of the web’s potential for changing both computing and the broader world, as well as what you need to learn to join the fun.
Those pieces digging deeper will appear on this site, but you can also stay in the loop on our latest analysis and coverage through our weekly web platform newsletter.
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.
From design processes to postmortem complexity, here are key insights from Velocity Europe 2014.
Practitioners and experts from the web operations and performance worlds came together in Barcelona, Spain for Velocity Europe 2014. We’ve gathered highlights and insights from the event below.
Managing performance is like herding cats
Aaron Rudger, senior product marketing manager at Keynote Systems, says bridging the communication gap between IT and the marketing and business sectors is a bit like herding cats. Successful communication requires a narrative that discusses performance in the context of key business metrics, such as user engagement, abandonment, impression count, and revenue.