The ORM anti-pattern

Yegor Bugayenko writes on ORM Is an Offensive Anti-Pattern, offering a pure OO alternative.

(I've posted too many links to my Google+ account. It's a ghetto over there as my public posts are science-oriented, programming is shared privately.)

For old time's sake, Uncle Bob

I forgot how good Uncle Bob can be. Thank you, The Old Reader: Transformation Priority and Sorting. Quoting:

In this post we explore the Transformation Priority Premise in the context of building a sort algorithm.

We also explore comic books as a pedagogical tool.

Want to read the rest? (In the interest of fair use you should follow the link.)

The JUnit forest

Edmund Kirwan damns the ubiquitous JUnit in JUnit's evolving structure. What's the problem? — galloping interdependencies. As a bonus, a spiffy graphical timeline of JUnit's structure.

The Java enum factory

This comes up in interviews with intermediate programmers (and some seniors), the "enum factory" in Java:

public final class Money {
    // Infrequent that new currencies created,
    // old currencies never vanish, just fade away
    public enum Currency {
        USD, PHP; // And many more

        // Additional fields as needed, e.g., locale

        public Money print(final BigDecimal amount) {
            return new Money(this, amount);
        }
    }

    private final Currency currency;
    private final BigDecimal amount;

    private Money(final Currency currency, final BigDecimal amount) {
        this.currency = currency;
        this.amount = amount;
    }

    // Appropriate methods
}

And elsewhere with static imports:

Money pocket = asList(USD.print(ONE), PHP.print(TEN));

The key observations:

• Amounts of money are intimately attached to a particular currency
• Currency has few qualities not attached to money
• Ok to add more currencies through code
• Code reads better with factory than without

Scala is Java, or how to grow to love the bomb

Twitter's Nick Kallen posts Why I love everything you hate about Java, a satisfying read about Scala, scaling and design patterns in the real world. More authors (including myself) should post like this.

That he dispenses with explanation why a Java article is really about Scala evidences this fact: Scala is Java, or what Java could have become in a better universe.

UPDATE: Why I love the blogosphere, also entitled Why I hate everything you love about Java courtesy of Roman Roelofsen.

Design, Don't do it

Are you designing a thread-safe front to a single-threaded resource? Relax.

The wrong way

Write layers and layers of complexly interacting abstraction over an object pool, letting the object pool (hopefully) protect you from threading concerns.

The right way

Use the JDK:

public class FooService {
    private final UnsafeResource resource;
    private final ExecutorService service;

    public FooService(final UnsafeResource resource) {
        this.resource = resource;
        service = createPoolFor(resource);
    }

    public <T, E extends Exception> Future<T> submit(
            final Work<T, E> work) {
        return service.submit(new Callable<T>() {
            T call() throws E {
                return work.use(resource);
            }
        });
    }

    public interface Work<T, E extends Exception> {
        T use(final UnsafeResource resource) throws E;
    }

    // Good place for an extension point depending on your needs
    private static ExecutorService createPoolFor(final UnsafeResource resource) {
        return newSingleThreadExecutor(new ThreadFactory() {
            public Thread newThread(final Runnable r) {
                return new Thread(r,
                        FooService.class.getSimpleName() + ": " + resource);
            }
        });
    }
}