For deeper considerations about public APIs, I suggest reading the most excellent:

“Practical API Design: Confessions of a Java Framework Architect (Hardcover)”

http://www.amazon.com/Practical-API-Design-Confessions-Framework/dp/1430209739

One question, for #8, if the code is to be used as a library (opensource)… would you still lean on removing the getters?

Normal java developers who consume your code tend to look for public getters all the time.

All-in-all, very intersting points!

About #3 there is in my opinion also a better solution. Give a look to the lambdaj library:

http://code.google.com/p/lambdaj/

and you will discover that your example could be rewritten without loops or anonymous inner classes as it follows:

List beerDrinkers = select(persons, having(on(Person.class).getAge(), greaterThan(16)));

Cheers
Mario

My only problem with passing everything in immutible chunks is that it requires so many helper classes to be defined and makes handling the program in the eclipse ide a lot more cumbersome. For a single boolean true/false flag to be added to a transaction requires a lot more work than just having a getter/setter.

Also the main concept of the Scala actors model can be easily accomplished using a BlockQueue with immutible messages in java. This would not scale to ultra high volumes however due to the context switching. I understand the ‘react’ command in Scala allows the next actor to stay on the same thread.

“No setters” – debatable. I am a believer in consistency and it should then be either the one or the other. However, I can think of way more scenarios for using setters than not using them. Therefore I think this shouldn’t be done. Generating setters is cheap in the IDE so just use them.

“Do not use loops for list operations” – that is IMHO by far the stupidest suggestion and an even more stupid justification: “easier to understand”. This is just preference and this whole thing on closures and predicates is nice but it looks like the hammer-nail pattern. Way too much noise there.

“Use one liners” – again preference. I would choose a third option:

public int add(int a, int b) {
return a+b;
}

“Use many, many objects with many interfaces” – again preference. Using interfaces doesn’t solve any problem and when using interfaces you can’t access the properties directly hence access through getter and setter methods and a direct contradiction to “No setters”.

“Use Erlang-Style Concurrency” – don’t know enough about this to have an opinion

“Use Fluent Interfaces” – again preference. This is the new JavaScript programming style but I don’t like it. The biggest downside is debugging as you cannot set a breakpoint on a specific method call as this is all one big line.

“Data Transfer Objects without setters and getters” – again preference although I can see some benefit of immutable objects. However, this should be available through the langugage which it isn’t. Java is not Erlang. Refactoring is easy with well designed objects, properly managed code and a good IDE. This has more to do with the quality of the programmer and the tools than the programming style.

Frank

New to your blog, and not trying to flame at all, but just my opinion on one in particular. I have a real aversion to suggestion #4. One-liners are awful things. Why should the number of characters in a method determine its formatting? This opens the door for any number of conditionals just to determine how your whitespace looks. The trivial example of the “add” method works, but this needs a giant EULA-style rulebook to avoid something like this trivial example:

public long fibonacci(int n){return n<=1?n:fibonacci(n-1)+fibonacci(n-2);}

It would be better suited to conditionals that the compiler would optimize anyway. Introduce a 55 char per line convention (unrealistic, but for example), maybe I should just call the method “fib” so it “fits on one line”.

Java is fine the way it is. It works and it isn’t hard to teach and use. Add all this stuff and it will be difficult to use.

Now, I wouldn’t agree ‘Use one liners’ is that good. I like one liners but still instead of
public int add(int a, int b) { return a + b; }

I would use
public int add(int a, int b)
{
return a + b;
}

Anyway, everybody has their own style.

Cheers,
Jarek

Scala is Java done correctly. And more.

More detailed response on my blog:

http://beust.com/weblog/archives/000517.html

http://enfranchisedmind.com/blog/posts/this-is-your-brain-this-is-your-brain-on-ocaml/
http://enfranchisedmind.com/blog/posts/object-burn-is-your-friend/
http://enfranchisedmind.com/blog/posts/some-final-patterns/

Java really screws you with #8. Unlike C# and Groovy, refactoring a public field is *not* trivial in the user code. So you’re pretty much toast if the object is ever going to be maintained moving forward. And if you’re going to making things fragile with malice of foresight, you should probably make the class final, too, just so you don’t take other people down with you. I’d actually suggest implementing #8 by writing that code in Groovy, even if you’re calling it from Java: you’ll get the implicit getters and setters for free, along with the code readability.

#1 “final makes code easier to read”: Final is yet another word that has to be processed by the reader. If the point is avoiding bugs, I would recommend FindBugs instead.

#2 You are using Tell Don’t Ask as the holy grail. For me, creating an isOlderThan() method goes against The Simplest Thing that Could Possibly Work and DRY (next: isYoungerThan, isOlderOrEqualsThan, etc). Sure, you can create a Domain method for every possible operation but then your domain classes will not scale too well, and it goes a bit against OO 101.

#3 Closures are one thing, but here you are changing one idiom with another. There is no gain in number of lines of code, readability and (certainly not) performance.

#4 one-liners does not improve readability, but save space, which is not the same thing. Breaking the expected vertical rythm makes code harder to read in most cases.

#5 implies that “many interfaces” == “better reusability”. This depends on the environment (the “forces” if you are talking about patterns), and cannot be applied as a general rule of thumb. I have seen plenty of idiotic interfaces out there, solving problems that proper encapsulation and inheritance would do much better.

#8 only applies if there is nobody else using your code. As soon as your library is used by third parties, refactoring would break things.

As a side comment, injecting the Twitter feeds into the comments section really lowers the S/N ratio of this thread.

Concerning the examples: There is a difference between example code that does want to show something, and real live code. The balance is fragile, between example code that is too simple and example code that is complex but doesn’t show the things it should show.

It would be great if Java had ‘final’ enabled by default, or if it had a shorter way to declare it.

It would be greatest if the semantics of ‘final’ were complete immutability, not just local variable immutability.

But Java isn’t like that, and forcing things may be useful sometimes, but most of the time they will just add noise to the code.

No, for simple data holder, paramter objects and data transfer objects, encapsulation is not needed and the generated boiler code in Java is doing harm (if you need to look through 3 pages of source just to detect, it does nothing more than hold data). If encapsulation is needed later, refactor (Think DRY and premature optimization)

> This way the class is reusable
And reusability …

> Data Transfer Objects without setters and getters

But not for encapsulation?

I think you need to get your software engineering goals straightened out.

Final does not make your entities immutable.

I agree with all points but #3 and #4.

More specifically, I agree with #3, only use with care: I’d prefer not to introduce additional dependencies (as Google Collections) if I only have a bunch of (ugly) loops.

Regarding #4, I find one-line methods almost unreadable, and I still prefer to break them.

Other than that, I’d sum up your most important advices as follows: think by interfaces, and always keep concurrency and side-effect-free in mind :)

Cheers,

Sergio B.

On top of this list, I think there is also “the next generation patterns/designs”. This list includes topics such as: DSLs, Dependency Injection, and the Properties Pattern (http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html).