Stop hating Java

I noticed that in the Ruby community “Java” is a synonym of pure evilness. It’s often used as an argument against some techniques.

“It’s Java all the way”


“If you drop static methods, then welcome to Java and its billions of useless factories.”


“Your mention of ‘factories’ gives me nightmares about Java-style over/premature abstraction where you need to interact with (and therefore understand) WAY too many different classes to get anything done.”

Those are some quotes that come from only one discussion triggered by Nick, me and Michal only because our ideas sounded a bit Java-like.

History

Part of the Java-hate comes from the historical reasons. When Rails appeared lots of Java people switched to it as it solved some of the problems with Java. I was one of them.

Rails was simpler than the existing Java frameworks. It let us solve most of the problems much faster than with Java. Ruby as a language was and still is a big advantage. Its syntax is more concise. Even though I still prefer Rails than Java based frameworks I don’t get why so many Rails people simply hate Java.

Java and XML

I always disliked the XML impact on the Java frameworks. It didn’t come from nowhere, though, let’s be fair. Java as a languages is not as readable as Ruby, so it wasn’t perfect for configuration. Yaml wasn’t popular and JSON was still not really mature back in 2000. Something had to be chosen and that was XML. What would you do better back then?

It doesn’t mean that whenever some Java-like idea is presented then somehow you have to be scared that you’d have to use XML again. Let’s try not to be biased and look at Java ideas without the XML bias.

Java and over-abstraction

Yes, often Java frameworks were very abstract and overgeneralized. Again, it was a result of Java lack of dynamic features. Whenever you needed a pluggable system in your code you had to abstract away some concepts in order to make it work. Ruby lets us do it much easier and that’s cool.

Java and good things

There is lots of good things that came from Java to the Rails world. Most of the TDD/BDD stuff comes from Java. Refactoring came to us from Java [UPDATE: What I mean is that those techniques came to the Rails world *through* the Java world, they're not originally from Java]. They became popular in the Rails world. That’s cool. There are other techniques that are great, but somehow didn’t get so popular:

Dependency Injection and Inversion of Control

These two techniques are great for many reasons. They suggest that you should expose your dependencies in the constructor or through setters. It reduces the usage of globals and static methods and simplifies testing. In my opinion they result in much better object oriented design.

POJO - Plain Old Java Objects

This is one of the places where I felt I made a step back when entered Rails from Java. In Java there was a clear trend that your business classes should be clear from any framework dirtiness. Persistence was configured and injected from outside (or through annotations). When your business classes are not polluted with framework stuff it’s much easier to test them in isolation. In Rails there are many tries but no good solution on how to test models without a database.

Aspect Oriented Programming

I was involved in the AOP movement in my Java life. AOP was the tool that let you intercept method calls and run some crosscutting code from one place. If you needed logging of method calls and params, it was just 3 lines of code in an aspect and all of your method calls were traced. Similarly, it was possible to handle persistence with AOP. Another part of AOP was composing classes from smaller pieces. Fortunately, this part now appears in the Ruby world in form of the DCI architecture. The dynamic part (interception of methods) didn’t get very popular. We have some limited AOP with filters in Rails controllers and callbacks in Rails models, but we could go further and use it for persistence or for logging.

Let’s stop the hate

It’s cool that we, as a community, strongly identify with some techniques. What I’d love to see is more tolerance for other technologies.

There are smart things in the Java world but we have to be open to reuse what’s most cool and replace the bad parts with Ruby awesomeness. When someone starts his talk with “In Java this problem is solved by …” don’t laugh and interrupt with quotes like “OMG, XML and factories again”. It didn’t happen only to me. I have seen this behavior at Ruby conferences very often. It's childish.

Many good things came from the Java world - we should love them for that.


There are more large Java systems than Ruby ones. They abstract for reasons. They use IoC and DI for good reasons. AOP is awesome when used in a good way. Let's learn more from Java - it will help us once we work more with larger systems and codebases. They already learnt their lessons.

[Discussion on Hacker News: http://news.ycombinator.com/item?id=2793227 ]

If you read this far you should and subscribe to my RSS. You can also buy me a beer at the wroc_love.rb conference. I'm one of the organizers.

Yes, Nick - class methods are evil

My friend Nick has just posted an interesting article about the usage of class methods. The article is really good, go read it first and then come back.

Are class methods evil?

In my opinion class methods are almost always a wrong approach to a problem. It’s not wrong as in “it doesn’t work” but wrong as “we can make it better”.

ActiveRecord and Rails

I blame the ActiveRecord pattern for the current class methods problem. Every Rails application I see is full of globals which are often results or causes of class methods. The problem with ActiveRecord is that it forces you to think in terms of sql tables. Almost every table exists as a class with lots of class methods that let you access the data from this table.

I mean methods like:

User.find(id)
User.all

etc.

Can we do better?

One of the things Nick suggested is using user_factory. Overall he’s right, but I don’t think user_factory is a good name for that. We’re not producing users in our app, right? The users live in the context of our app. Is it a shop or a game or maybe a portal? Then create a class for that. This is your “factory”. Once you have it, always access users through this object. Not only users, you can do the same with products, prizes etc.

Instead of User.find(4) you now have game.users.find(4) or better game.find_user(4). You still gain from the ActiveRecord methods, without using the class methods, though.

How to implement the app class?

There are two ways that I’m aware of. Both are not ideal, mostly due to the way ActiveRecord works, but in my opinion they improve the code quality.

1. Create an ActiveRecord model for that.

If your app is a game then create a model called Game with the associated table (games). Yes, it will possibly have only one record and yes it may add some overhead to the queries that are generated by the ActiveRecord framework. Thanks to that however you may have only one “singleton/global” in your app.

class Game
  has_many :users
  has_many :prizes
  ....
end

I usually put the implementation in the ApplicationController and have something like:

def game
  Game.find_by_name(“Music Challenge”)
end

Then, in every other controller I can access the game object and find all the data I need through its scope.

2. Non-ActiveRecord class

The other way assumes that you hide the globals in this class. It can be done in many different ways. One of them is:

class Shop

  def products
    Product.all
  end

  def find_product(id)
    Product.find(id)
  end
end

What’s my choice?

Overall, I prefer the first way. It has a nice side-effect that once you have the game/shop model you can easily turn your application from a single game to a platform of games (which we actually did in one project, but that's another story).

I also try hard to find the way out of the ActiveRecord and sql/nosql dependencies and go into a pure OOP direction with madeleine/prevayler-like tools.

What’s your choice? Do you see the problem with class methods?


If you read this far you should and subscribe to my RSS