System.out.println Debugging

Who hasn't done the following? Adding appropriate System.out.println statements to your code, in order to actually see what is going on.

I admit to using it once or twice. I must even admit that once or twice I've managed to accidentally check my printlns in.

I found the following Small Gem in the Tips and Tricks of Eclipse^[1].

A picture of the properties of a breakpoint in Eclipse is available to the left.

I'm going to assume that a similar trick can be used in other IDEs.

Some special notes about the breakpoint:

• it's conditional
• it will only suspend execution when the condition evaluates to true
• the condition will always evaluate to false
• conclusion: the breakpoint will never suspend execution
• it contains System.out.println statements

In effect, we have created a System.out.println statement, without actually changing the code.

This has certain advantages:

• Debugging code isn't actually checked in by accident
• You do not actually need to have the source code or to deploy anything to get the print statements

Already it is being used at my workplace by the Helpdesk for easy access to which SQL queries are sent to the database.

References

[1] Tips and Tricks (JDT) (Java Development Tools

Eclipse Java development user guide

Trainwreck vs. Method Chaining

I thought it worth while to expound on the differences between a train wreck and method chaining.

Whereas a trainwreck is a bad idea, method chaining is an excellent idea. This blog will try to explain why these two are polar opposites on the good/bad scale, even though the syntax differs very little.

Trainwreck

A trainwreck is a bad idea. It provides an Object A with in depth knowledge of several other objects. Knowledge that should be contained in the individual objects instead of Object A.

In code it would look like follows:

public class A
{
    public void someMethod(B b)
    {
        b.getC().getD().getE().doThing();
    }
}

A Trainwreck breaks the Law of Demeter^[1] (and everyone knows, if you break a law, you have to go to jail).

A solution would be to just tell B to do it, and let it figure it out.

public class A
{
    public void someMethod(B b)
    {
        b.doThing();
    }
}

Method Chaining

Method chaining is an excellent idea. The methods used always return the Object itself. It's a good way of constructing an Object without having to resort to multiple different Constructor methods with varying (large amount of) parameters.

public class Person
{

    private long id;
    private String firstName;
    private String lastName;
    private String address;
    private String telephone;
    private String title;

    public Person(long id)
    {
        this.id = id;
    }

    public Person setFirstName(String firstName)
    {
        this.firstName = firstName;
        return this;
    }

    ...
}

public static void main(String[] args)
{
    Person mrBear = (new Person(1l)).setFirstName("B.").
              setLastName("Bear").setTitle("Mr.");
}

Method Chaining does not break the Law of Demeter^[1]. It doesn't even talk to friends (in this case), but only to itself.

Here I have used a simplified example. Mostly you'd create a PersonBuilder to make Persons.^[4]

For some great uses of method chaining check out [2] and [3].

References

[1] Glossary

http://randomthoughtsonjavaprogramming.blogspot.nl/p/glossary.html

[2] FluentInterface

http://martinfowler.com/bliki/FluentInterface.html

[3] Expression Builders

http://martinfowler.com/bliki/ExpressionBuilder.html

[4] Too Many Parameters in Java Methods, Part 3: Builder Pattern

http://marxsoftware.blogspot.nl/2013/10/too-many-parameters-in-java-3-builder-pattern.html

Examples of a HashSet - Followup

See Examples of a HashSet for the original article.

It seems according to "Unique hashCodes is not enough to avoid collisions", even perfect hashcodes might not be enough for for example HashMap collections.

Red Soup

Recently had a real life experience that I could map to Software Design.

Occasionally, I or one of my colleagues gets beverages for everyone. The scheduling is: the one who wants to have a beverage gets some for the rest as well and queries their preference beforehand.

In this case, the job landed on one of my colleagues.

The conversation went something like:
Guy1: What would you like?
Me: I'd like some Red Soup.
Guy1: What kind of Red Soup?
Me: Red Soup! You're the Factory, figure it out.
Me: Convention Over Configuration!
Guy2: Should he draw you an UML diagram? As long as it implements or extends RedSoup.
Guy1: With Cream?
Me: That's an implementation detail. Not interested! Red Soup! Go!

It left me in stitches, I'm geeky like that.

(added an overview of the different arrows in UML. I always get confused.)