Archive for the ‘API and Patterns’ Category

Functional Java – partial function application, the LOD and structure agnostic access

March 21, 2016 Leave a comment

It’s been a while since I last wrote something about programming on my private blog and since a lot has been said about Java 8 lambdas, I did not feel to add a lot more. But I recently saw a colleague’s blog on Intel’s Inside Blue about Lambdas and why a functional programming style matters. That motivated me to write something again, and tackle this topic, putting an emphasis on a specific problem and how Lambdas helped me solve it.

Read more…

Into the Void: Refining Java beans with rare weapons

July 17, 2011 2 comments

Lately I’ve been experimenting with the Void class, because I asked myself what I could do with it that I haven’t yet thought about. I came across a use case that I’d like to share with you, because I think it is possible to beautify one’s code with it. In the process of slightly refactoring a Java bean in order to get a nicer, more refactoring-proof way of dealing with beans and reflection, I’m also using an inline-assignment in a way that you might already have come across, still I have hardly seen it anywhere in the wild, even though I find this particular use case for inline-assignments one of the best there is.
Read more…

Java actor framework “Kilim”: A solution without a problem?

November 26, 2010 3 comments

Some time ago I read a posting from a workmate, that was linking to an IBM developerworks article about the actor-framework “Kilim” and he seemed to be quite fond of it. Since I know this guy’s a very skilled technician and since actors are one of the bigger hypes in software technology nowadays, with languages like Scala openly supporting that concurrency model, and since the IBM developerworks articles are usually quite good, I instantly dived into it, only to be left perplexed. Read more…

Reflection without Strings

August 9, 2010 4 comments

Sometimes reflection is very handy, but using reflection often involves referencing methods by Strings, which can get you into major trouble when you are refactoring your code. If a method belongs to an interface though, there is salvation. But let me first tell you how it started and what I did about it. Read more…

Minimizing ripple effects

April 6, 2010 1 comment

In the good old times when racing was dangerous and sex was safe and real programmers coded machine language we were used to use jumps and branches to addresses or labels if you had more than just a ML-monitor. BASIC just took this paradigm to a higher language level and the art of programming involved tracing all the jumps and conditions at the same time until Edsger Dijkstra spoiled it all – and rightly so! There are better ways to waste your testosterone and show you’re a real man than working successfully with untraceable spaghetti-code no one else understands – including yourself some months later. Sadly you can still create a tangled mess if you’re programming in Java and other OOP languages alike. Often you find yourself in a situation where you have to change something which would break a lot of code, because that small change you need to make ripples through several classes. The higher the fan-in-complexity of your code is, the worse it gets. This is why some code analysis tools punish a high fan-in-complexity, which may be misleading if you take the DRY-principle seriously. Especially if you work on frameworks you need to take countermeasures to avoid ripple-effects so you can continue to develop your framework while it’s being used. Let me introduce you to a coding style that helps to reduce ripple effects.

Read more…

Using annotations for validation

March 20, 2010 2 comments

There is one common case I often come across and that’s validation of parameters. There are different situations in which you like to validate parameters, the most common case is validation of method parameters, usually performed with guard-clauses and assertions. This is not what I’d like to write about in this blog. I may come across this later. This time it’s all about annotation driven validation on fields. Read more…

Dealing with immutability and long constructors in a fluent way.

March 10, 2010 9 comments

I use to state that the best thing to do is to keep your code simple and clean. But if your task is to design an easy-to-understand and easy-to-change API, this may be a bad advice. There simply is no silver bullet in programming and simplicity ain’t one either.

There is a common case you may have encountered more than once, which is long constructors with repeating types. You’re likely to see them in immutable classes. I’m not going to discuss why immutable classes are desirable, I’m going to talk about easing the pain to construct them. Read more…