property-based-matrix-testing-tutorial VS functionaljava

For instance, in a previous post of mine called Property-Based Matrix Testing in Java, I've touched base on how the CartesianProductTest and the CartesianEnumSource annotations have helped me trim down this:

As demonstrated in this repository, executing both test cases in the same test class, using JUnit's platform, will print out:

A few side-notes about this code: - you need some sort of "wrapper" or "container" in order to use functional methods like map/flatMap/filter/etc on some object - here I used Optionalfor testing because it's available in standard Java: Optional describes an object that may or may not be available. - A more suitable "wrapper" for this use-case could have been Try which describes the result of an execution that may succeed or fail, see vavr has a Try for example, functionaljava has Either - map transforms A -> B (would make sense for your mapToUser) whereas flatMap transforms A -> Optional (or whichever "wrapper", would make sense for your userService.save if suppose the saving operation can fail) - Here is a working example for you :) - practise exercises: 1- replace the "wrapper" Optional with List, there is almost no change of code, this now gives you the ability to process lists of users 2- import vavr and replace the "wrapper" Optional with Try, there is almost no change of code, this now gives you the ability to process operations that may fail - Enjoy functional programming, you'll find java is rather verbose and quickly gets clunky for FP, consider switching to another language

? Sometimes passing a lambda (or other function) as an argument is a simpler approach to specialization than defining a subclass. That I think is mainstream and accepted in Java today.

There is a lot more to "functional programming" than that, such as the use of persistent collections. In some cases (such as managing the symbol table in a compiler) those methods lead to good efficiency and great simplification, in other cases they are ways to make easy problems punishingly hard.

pidove builds on top of ordinary Java Collections and doesn't push more exotic approaches as does

http://www.functionaljava.org/

We can simulate using type components in modules in Java by using parametrized classes, the type parameters correspond to type declarations in a ML signature. I found an example monoid definition in Java if you want to see how that looks. You can see that the "functors" are kept inside the class definition, though I don't know if it's necessary, I don't really know Java. You probably get weaker abstraction, because you can't have some monoid with an unknown carrier type, you always know the carrier type - it's just the type parameter A in Monoid.