Fun fact, I thought I had already written this post, but when I wanted to reference it, I found out that I didn’t. In this post, I’d like to describe my approach when choosing a dependency. I’ll first define what I mean by dependency in the context of this post. Then, I’ll list a grid of several criteria to analyze possible dependencies with. What is a dependency?

In my penultimate post, I described the use-case of an e-commerce shop. In general, interactions in such a shop are the following: You can browse a catalog of itemsEach item has a price tagYou can put x items in your cart It’s when the exciting part starts. On most pages, you want to give users a condensed view of their cart’s state. Here are a couple of options for the state’s view: Empty/non-emptyNumber of cart linesNumber of itemsTotal cost.

In Java, it’s widely admitted that reflection - usage of the java.reflect API, comes at a high cost in terms of performance. Older Java versions had huge performance overhead, while it seems that newer versions bring it in the acceptable range. But what does 'acceptable' really mean? This is the question I asked when commenting on a performance review that advised to replace code based on reflection by standard code.

The first rule of Fight Club is: you do not talk about Fight Club. The second rule of Fight Club is: you do not talk about Fight Club. I guess the same could be said about refactoring. That would first requires to define what I mean by refactoring in the context of this post.