Code Scavenger’s Chronicles

Ah..Have you ever wondered how all these social networking sites show you, your friend’s friends and their distance from you? Not an easy problem if you have millions of users across geographies.

Case in point: LinkedIn. All user searches with a “name” return users and an indication (1st, 2nd, 3rd) of their distance from you provided they are at most 3 degrees away from you. What do they use? Good old graphs! 40 instances in production. About a 100Million+ edges! Wow..Wouldnt that be a good problem to work on?

What if you used a Object DB instead? Would it even have a fighting chance?

See this. Slides 19-20.

<yodaspeak>DIG. MORE. I MUST</yodaspeak >

Dang..every time I look at the guice code, keep finding neat little nuggets lying around – the operative word being “neat”. For instance, look at ToStringBuilder. What?? A Builder for toStrings? Who would have thought of that? Well, Crazy Bob Lee did!

Here’s the usage from a consumer class.

public String toString() {
return new ToStringBuilder(Binding.class)
.add(“key”, key)
.add(“provider”, internalFactory)
.add(“scope”, scope)
.add(“source”, source)
.toString();
}

Isn’t that neat? People at the Big G are thoughtful enough to make writing toString() structured and a breeze at the same time.

Where does this ‘neatness’ come from? Why is it that any code that you see at work (read our day jobs – not all of us work at google) tends to be so horrific & predictable that a page down while inspecting code doesn’t miss much worth the traversed screen space? Why is it that so-called innovative and path-breaking software (mind you; such stuff is even patented) is built on humongous mountains of code filth?

Nope – I don’t have answers to these questions. Do you?

PS : Mind you, I do have a *solution* to the problem; but not an *answer* to the question – Maybe I’ll write an article with answers when I am feeling more upbeat about the work that I get to do. Who knows?

Prediction???
Factories are out; Builders are in.

Basis
Here is some “gyan” laced with content filched from Josh Bloch’s prezo on Builders in Javaone 06/07.

In the Builder pattern:-
• Builder constructor takes all required (manadatory) params
• One setter for each optional parameter
• Setters return the builder to allow for chaining
• One method to generate instance
• Pattern emulates named optional parameters!

Here is an example invocation/usage:-

NutritionFacts locoCola = new NutritionFacts.Builder(240, 8).sodium(30).
carbohydrate(28).build();

Here is the builder code for the example above:-

public class NutritionFacts {

    public static class Builder {
        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }

        public Builder calories(int val) {
            calories = val; return this;
       }
       ... // 15 more setters

        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }

    private NutritionFacts(Builder builder) {
        <copy data from Builder to NutritionFacts>
    }
}

But writing a builder for each object gets oh so tedious every time. Cant we have something easier (read less code) Mr. Bloch?

Solution

Well, Robbie Vanbrabant has one. See BuilderBuilder.

For any object that you need to create a builder for; this is what you need to do:-

public class Example {
    private final String mandatory;
    private final int optional1;
    private final char optional2;

    private Example(ExampleBuilder builder, String mandatory) {
        this.mandatory = mandatory;
        this.optional1 = builder.getOptional1();
        this.optional2 = builder.getOptional2();
    }

    public interface ExampleBuilder extends Builder {
        ExampleBuilder optional1(int optional1);
        ExampleBuilder optional2(char optional2);
        int getOptional1();
        char getOptional2();
    }

    public static ExampleBuilder builder(final String mandatory) {
        return new BuilderFactory(BuilderType.SIMPLE_SETTER)
            .makeRisky(ExampleBuilder.class, Example.class, mandatory);
    }

    public String toString() {
        return new StringBuilder()
            .append(getClass().getName())
            .append(String.format("[optional1=%s, optional2=%s, mandatory=%s]",
                optional1, optional2, mandatory)).toString();
    }
}

And how do we use it?

Example.builder("Mandatory!").optional1(4).build();

Thats it!

No need to write the Builder code. Just write the interface for the Builder and you are ready to roll!

Well, how does this work?

Dissection

Remember Java Proxies and Reflection. Thats the magic behind it. See the code for BuilderFactory.

Notice how makeRisky() creates a callback handler BuilderCallback and passes it on to make(). Essentially make() creates a Proxy for Class V using an invocationhandler called BuilderInvocationHandler. BuilderInvocationHandler takes in the callback BuilderCallback as an argument.

As is mostly the case with invocationhandlers, the BuilderInvocationHandler creates a map backed storage for all the attributes of Class V, which is accessed whenever a set for an attribute is invoked via invoke(). Note that the set() for an attribute in this pattern always returns the Builder T. In the case where build() is called, it delegates the call to call() method on the callback handler BuilderCallback which returns an object of Class V.

So, essentially the trick works flawlessly with a sprinkling of reflection and callbacks. Cool!

NOTE: Robbie got this done last year. I just happened to stumble over it now!

JEDI Moral: Less YouTube Must Watch This Year

How often have your needed lookups based on keys as well as values in a Map? Some programmers (read <1%) worth their salt look at such an opportunity to write their own collection class. However most others end up cribbing about the collections library.

Well, rescue is at hand now.

Look up google-collections.

See BiMap? Exactly what you need!

If you ever needed multiple values attached to a single key; well, here’s MultiMap.

To the credit of the library designers; they are still upholding the java.util.collections tradition of providing classes with static methods that operate on or return the new collection types. See the class names ending in collection type plurals i.e. Multimaps, Multisets etc.