This time, I will lay out my concepts for nice and maintainable programming in java, using a more functional style, but pertaining the imperative approach to have it still look like java. The driving force behind this is, first of all, this: I want to write code which is fast, maintainable, testable and easy to understand when you revisit it in 5.000 years.
#On Strongly imperative programming and its problems
Thats what all the following parts will be about: Its not that imperative programming is bad (at least not in java), as some people might suggest. However, this approach has indeed a lot of problems, which reach far deeper than just the obvious concurrency issues. The real problem tends to be that is very hard to refactor and re-design strongly imperative code with a lot of side-effects into smaller portions. Of course it _is_ possible, but you will not always end up with something that is really "reusable".
Instead, the refactoring will usually yield in a lot of imperative methods which are not useful by themselves and have to be executed in a special order for a special usecase. Thats still good, but is just not as rewarding as developing something that is REALLY reusable.
#Advantages of imperative approaches
Nearly all languages today are imperative, and I guess nearly all of us (including me) have started in that style. Its main selling point, I think, its that it feels more natural for beginners, which simply will need the flexibility of re-defining their variables all the time.
Also, imperative programming is simply the logical conclusion of our work: We want to introduce side-effects, after all. Otherwise, why are we coding? Note: This is answer is not really correct. See Haskell in which even IO and the like are implemented in a very functional way. But I guess its "correct-enough" for all of us for now.
So, implementing workflows and the like in a very imperative way should be ok for now. This code will not be reusable most of the time anyway.
#Advantages of functional approaches
Functional programming has no sideeffects, as every function has input values (which are not mutable) which result in output values which are used as an input for the next function. So output values are indeed what they are meant for, and inputs never modified.
This approach strongly relies on closures (function variables) and really shines for 90% of the code we are working on, esp. Collections and DataStructures. It should be obvious that I want to advocate this style of programming even in java, were it is not a first-class citizen, but using it will still be very rewarding.
#On closures and other advanced functional concepts
Quick answer: I do not advocate to use them in java. Its a pity and a very limiting factor in my design, but I won't use inner classes heavily for all collection operations. They are hard to read, when used on masse, and results in java code which is not easy to understand for the run-of-the-mill java developer. We will have to wait for java 7 for this issue, I have to recognize. (or use JEDI).
Keine Kommentare:
Kommentar veröffentlichen