Yeah, it sounds like functional programming is what you need... however there are some things that you want to keep in mind, even when you go functional. There's no point in using OOP or functional languages if you don;t understand
why OOP/functional programming was built. It's going to be hard for me to not sound preachy in this post, so please take the rest of this post in the spirit of goodwill that it is being offerred.
The main reason you don;t want to do everything static all the time is because
a) you lose the buildy-blockiness
A big reason why OOP was a big leap over procedural languages is because of it's buildy-blockiness. You think of components as Lego pieces.. and you build the ability to piece them together. If one piece needs to change, you throw the piece away and put it in another without touching the piece that doesn't need to change. You literally cannot do that with static functionas/procedural languages. Why we use OOP is because we know we are going to be constantly changing the programs we write.. and we want them to be easy to change, not just work right.
After all, if you had a guarantee that you never had to touch your code again.. why would you even use static functions? Just frigging put everything in your Servlet.process method.. right? That's how I did it when I programmed in Basic on mah ZX Spectrum. Just write the whole program in a single main method. Worked for me!! The program works.. Me and my brother made clones of 2 screens of Mario Bros. Didn't even need to use for loops. GOTOs everywhere. The whole reason why we went from GOTO loops to for and while loops is because they help us avoid spaghetti GoTOs which helps us maintain the program. The whole reason we go from that to building procedures is to make it easy to maintain the program. Yes, may people don;t understand this and end up doing OOP the wrong way.
It;s a series of lessons that people have learnt over the year that has led to OOP. The people who came up with OOP were tired of the headaches caused by having to change and maintain procedural code. And yes, we are continuing the same spirit forward as we move into a functional world.
Think what would happen if Java classes themselves weren't built as building blocks . Let's say Java was ALL STATIC ALL THE TIME. And it had a static method for reading from a file and a static method for reading from the network. Now, you wrote this neat little program that reads a file from the disk parses it and cures cancer. Tommorrow, someone comes to you and tells you.. hey I got this file on a server, download it and cure cancer.. and you tell them no.. can;t cure your cancer until you send me the file. How effed up is that?
b) there is no way to mock the function
Again, this goes toward the buildy-blockiness of OOP. You need to be able to
test. and when you are thinking of building blocks, you need to be able to test building blocks on their own.. except that some building blocks inherently need other blocks. Let's say you were testing your service layer.. well your service layer needs a data access layer to work. So, how do you test it in isolation. Well you replace the data access layer with a mock data access layer and test the service layer in isolation
c) there is no way to proxy the function, which means you cannot use aspects
I won;t delve into this in too much detail because it;s a huge subject. I encourage you to look at AOP and what advantages it gives. Primarily, it allows you to separate boiler plate code from "real" code, which again helps maintainability. Aspects will be impossible without proxying.. and proxying would be impossible with static functions
Yes, so again, probably fuctional programming is what suits your style. However, even if you do adopt functional programming, you stilol need to remember the
lessons that people have learnt which led to OOP.. and similar lessons that have led to functional programming. You need to make sure that
a) you don;t lose buildy-blockiness nature of your application
Functional languages essentially make each function a building block. So, when you design your functions you need to make the easily replaceable. Make your functions self-contained. make them so that multiple functions don;t go trampling over each other. Make them do one thing and do it well. Tight cohesion.. low coupling
b) you need to make sure you test your code in isolation
the function as a variable nature of functional programming helps you there too. You could plugin mock functions into other functions.. and you can test your functions in isolation. However, you need to be thinking about testing when you build your functions as you are building it. You cannot have testing be something you do after you are done programming.
c) you need to make sure you seperate concerns.
Let's say you have 2 functions; one that saves widgets and another that saves thingamajigs.. do you do this (all pseudo code here
or do you do this
Which one is easier to maintain and read?
1
