Sometimes a constructor doesn’t communicate intention very effectively. This could be because instantiating the class in question isn’t as straight-forward as “creating a new object”, or because there are many alternative constructors. In those circumstances it might be useful to use well-named static or non-static methods to create instances of the class instead.
I want to describe a situation I came across where designing for testability seems to be in conflict with the always-valuable principle of loose coupling.
I’m constantly trying to become better at estimating how long a development task will take. As one step in this process I decided to create a simple web-based timer which I could use to measure time. Shouldn’t be too hard, I just needed a simple stop watch — the simplest thing that that could possibly work. That’s what I thought at least.
While evolving a design is good and nice one has to remember that even though big design up front might not be a good idea, all the hard design work still needs to be done at some point. Otherwise you’ll just end up with a big piece of garbage. Therefore, while starting with a story, do take time and think it through and answer a couple of the following questions for yourself.
I just wanted to describe what for me became an “eye-opener” regarding Test-Driven Development; that when you remove duplication, you should look for not only duplication of logic, but also duplication of data.
Among Java developers, there exist different ideas about how to implement the equals() method. The disagreement is about whether to allow subclasses to be considered equal or not. I quickly describe the difference between the two alternatives and give my take on the problem.
Not many people would argue that a complex and difficult-to-understand solution is better than a simple and easy-to-understand one. And still, we often tend to end up with more complex solutions than we need and/or would wish for. This is generally for two reasons. Either we think to little, or too much.