DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Two Cool Java Frameworks You Probably Don’t Need
  • Mastering Unit Testing and Test-Driven Development in Java
  • Comprehensive Guide to Unit Testing Spring AOP Aspects
  • Improving Java Code Security

Trending

  • Evolution of Cloud Services for MCP/A2A Protocols in AI Agents
  • Event-Driven Architectures: Designing Scalable and Resilient Cloud Solutions
  • Recurrent Workflows With Cloud Native Dapr Jobs
  • AI, ML, and Data Science: Shaping the Future of Automation
  1. DZone
  2. Coding
  3. Java
  4. Writing Clean Predicates with Java 8

Writing Clean Predicates with Java 8

By 
Kevin Chabot user avatar
Kevin Chabot
·
Jul. 02, 13 · Interview
Likes (8)
Comment
Save
Tweet
Share
155.7K Views

Join the DZone community and get the full member experience.

Join For Free

in-line predicates can create a maintenance nightmare.

writing in-line lambda expressions and using the stream interfaces to perform common operations on collections can be awesome. assume the following example:

list<person> getadultmales (list<person> persons) {
  return persons.stream().filter(p -> 
    p.getage() > adult &&
    p.getsex() == sexenum.male 
  ).collect(collectors.<person>tolist());
}

that’s fun! but things like this also lead to software that is costly to maintain. at least in an enterprise application, where most of your code handles business logic, your development team will grow the tenancy to write the same similar set of predicate rules again and again. that is not what you want on your project.  it breaks three important principles for growing maintainable and stable enterprise applications:

  • dry (don’t repeat yourself): writing code more than once is not a good fit for a lazy developer ;) it also makes your software more difficult to maintain because it becomes harder to make your business logic consistent
  • readability : following clean-code best practices, 80% of writing code is reading the code that already exists. having complicated lambda expressions is still a bit hard to read compared to a simple one-line statement.
  • testability : your business logic needs to be well-tested. it is adviced to unit-test your complex predicates. and that is just much easier to do when you separate your business predicate from your operational code.

and from a personal point of view… that method still contains too much boilerplate code…

imports to the rescue!

fortunately, we have a very good suggestion in the world of unit testing on how we could improve on this.

imagine the following example:

import static somepackage.personpredicate;
...
list<person> getadultmales (list<person> persons) {
  return persons.stream().filter(
    isadultmale()
  ).collect(collectors.<person>tolist());
}

what we did here was:

  • create a personpredicate class
  • define a “factory” method that creates the lambda predicate for us
  • statically import the factory method into our old class

this is how such a predicate class could look like, located next to your person domain entity:

public personpredicate {
  public static predicate<person> isadultmale() {
    return p -> 
      p.getage() > adult &&
      p.getsex() == sexenum.male; 
 }
}

wait… why don’t we just create a “ismaleadult” boolean function on the person class itself like we would do in domain driven development? i agreed, that is also an option… but as time goes on and your software project becomes bigger and loaded with functionality and data… you will again break your clean code principles:

  • the class becomes bloated with all kind of function and conditions
  • your class and tests become huge, more difficult to handle and change (*)

(*) and yes… even if you do your best to separate your concerns and use composition patterns

adding some defaults…

working with domain objects, we can imagine that some operations (such as filter) are often executed on domain entities. taking that into account, it would make sense to let our entities implement some interface that offers us some default methods.

for example:

public interface domainoperations<t> {
  default list<t> filter(predicate<t> predicate) {
    return persons.stream().filter( predicate )
      .collect(collectors.<person>tolist());
 }
}

when our person entity implements this interface, we can clean-up our code even more:

list<person> getadultmales (list<person> persons) {
  return persons.filter( isadultmale() );
}

and there we go…

conclusion

moving your predicates to a predicate helper class offers some good advantages in the long run:

  • predicate classes are easy to test and change
  • your domain objects remain clean and focussed on representing your domain, not your business logic
  • you optimize the re-usability of your code and, in the end, reduce your maintenance
  • you seperate your business from operational concerns

references

clean code: a handbook of agile software craftsmanship [robert c. martin]

practical unit testing with junit and mockito [tomek kaczanowski]

state of the collections [http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html]

notes

the code above is served as an example to illustrate the principles i wanted to discuss. however, i did not proof-run this code yet (it’s still on my todo list). some modifications may be needed for your project.

unit test Business logic Java (programming language)

Opinions expressed by DZone contributors are their own.

Related

  • Two Cool Java Frameworks You Probably Don’t Need
  • Mastering Unit Testing and Test-Driven Development in Java
  • Comprehensive Guide to Unit Testing Spring AOP Aspects
  • Improving Java Code Security

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!