By using some function programming basics your code can read and perform better than when you found it. By recognizing these patterns and the value they bring, you will find yourself recognizing this situation in many places and it will become easier to have smaller refactors that don’t slow you down on your current estimate, but give you the peace of mind that you will save some time down the road.
This will cover (IMHO) the basics of functional programming that benefit any codebase; iterative functions, OOP classes and any ball of mud you run into
Immutability
Immutable parameters don't change the value internally. use this value to create a new onethis is referred to as ‘side effects’
This is essential when doing concurrent programming. The data you put into that thread can’t have a hard reference (or any ref) to the global value.
By default, try to keep inputs immutable. Be efficient at copying the data you need and returning a new set (or reference to that set). You can enforce this in Java with the final keyword. In python, you can use tuples to pass arguments into functions (instead of lists)
Functional Composition
When you have many functions in a file, the callee has to know all of the details of the internals to be able to create the behaviour desired by combining the function calls in the correct sequence.
This really violates basic encapsulation and leaving this will cause some messy coupling between components and pieces of code will call specific functions. Easier to provide an interface that has specific behaviour. There is a parallel here with the Facade pattern in OOP, provide a simplified interface for the behaviour of the component and then refactor all the reference to that functionality to the new interface. This is a great re-factoring strategy, to add some functional design to your classes. Use abstract data types or interfaces to enforce the behaviour of the internals.
Higher-order functions
The most common are using map, reduce, and filter
- Map - apply a function to all elements in the list. The list won’t change, but he values in the like will
- Filter - remove elements from the list that don’t satisfy a certain condition
- Reduce - apply a function to each element, and combine all results into one value
When using map, the elements in the list will change, so these are mutable elements. For Filter and Reduce, you are reading the elements and producing a new output. With these immutable values, you could use partition the list, and use concurrency to run filter and reduce in parallel.
Monoid
This has an obscure name; but its really some very fundamental algebraic rules for designing functional behaviour. Monoids have properties and its a good idea to follow these as a guidelines when creating the functions that are used/applied in the higher order functions like map, reduce and filter.
Closure - types inputs is type output. When you pass in integers, you have integers returned.
Identity - depending on operation, the base value for type
- for addition: 0 (1 + 0 = 1)
- multiplication: is 1 (1 * 5 = 5)
- concatenation is empty: "this" + "" = "this"
Associative
- a + b = b + a
- a * b = b * a
Recursion vs Iteration
Recursion can improve readability, but it comes at a cost of execution. you can exhaust the resources of your stack pretty easily when dealing with large datasets. Use iteration when possible for more predictable linear nature of the execution
Conclusion
By using some concepts from functional programming and being able to see these patterns emerge when refactoring code; the quality and consistency of the refactored result will increase in quality. This is from using tried and true concepts that, like many patterns, will just emerge from your work and add consistency so your teammates will be able to more easily read and maintain the code.
