I find myself often wanting a way to dynamically access a field in an object regardless of the object so I have started to do things like this;
—————-
final class Person {
String firstname;
String surname;
short age;
Person mother;
Person father

public enum FatherAccessor implements Function {
instance;
public Person apply(Person input) {
return input.father;
}
}
}
————-
Obviously this is a simple example but its served us well. This style of programming allows you to produce a ‘view’ of an underlying collection regardless of where and what it is, eg;

Set people = getPeople();

Iterable father = Iterables.transform(people,Person.FatherAccessor.instance);

List beerDrinkers = persons.filter(both(canDrinkBeer, isMale));

both is a helper Method to combine predicate functions to a new one where both has to be fulfilled.

I think that’s the way the code should look like.

1) you’re going to have a loop somewhere one way or another (e.g. inside the filter method), but I absolutely agree that the closer you can get to a functional style, the better.

2) One liners… use with caution. Even trivial things can be easier to step through in a debugger if you have the calculation separated out line by line. Also, you’re not going to gain much efficiency by compressing something like your example add method.

@Jan Wilem: Scala has changed me too, although my Java was very functional, pragmatic and non-mainstream already.

I might think that predicats are just that, predicates. And expresses as functions in FP languages and objects in OO languages. But even in FP languages they are manifestations, not functions per se.

Stephan
Vice CTO – brands4friends

I do not agree with you that predicates is OO. Rather they are the natural way to express a function T -> bool in an OO language. If you think of how closures work (i.e. closed functions with stack plus code) they are essentially an object passed around. In that sense, they are very close to what a predicate does.

Pascal-Louis Perez
CTO – kaChing

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

AND

@ Ignacio Coloma – August 11th, 2009
“#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.”

The problem here is the “expected” vertical rhythm. In the western world, we write from left to right. Even mathematical formulas are from left to right. You would not find a mathematician writing

y =
f(x)

f(x)
=
x**2
+
2x
+
5

Therefore, the overdone vertical writing style is already “unnatural”, but conditioned over a long time of simply doing it, and perhaps a relict of the assembler times, where code was read in columns.

At the time you get used to grok such one-liners as “expressions”, like a formula in math, it feels uncomfortable to have such simple expressions artificially split. This splitting of even the simplest expressions is again an artefact of the verbosity of Java.

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

as:

int add(int a, int b) = { a + b}

or even:

add(a, b) = a + b

The problem is, that all the boilerplate makes it hard to find the elementary things, so you “emphasize” them by putting each on an own line.

NB:
Another old generation style is, to write all attributes at the beginning of a class and getter and setter below, sometimes sorted in all getters and all setters apart.

This style feels like the very old Cobol days with its different sections.

A NG style I sometimes use is, to group the property parts together:

private String name;
public String getName() { return name; }
public void setName(String pName) { name = pName }

Querydsl supports JPA, JDO, SQL, Lucene, Java collections and RDF.

So instead of inline strings you can use fluent type-safe Java calls.

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).