Bendy classes and dynamic programming
Jack Herrington has published this article: Going dynamic with PHP claiming to show some things PHP can do which Java can't.
Okaaaay... This is another of the articles in the meme that dynamic languages are great, and rigid languages are uncomfortable. I don't know if I got the analogy right this time, let me know please?
The problem he poses is about implementing the database interface classes. The traditional method might be to write one class per database table, expose get/set methods for each field, etc. You'd end up with a tedious implementation and a lot of typing of highly similar code. He poses three possible solutions, and claims that PHP implements the best of the three.
One problem with the article is there's more than three possible solutions. The problem with the proposed solution is it doesn't give early warning of broken code, leading to greater expense to fix coding problems.
Whever a writer presents a problem .. and then presents a selected list of solutions .. the writer (maybe unknowingly) is trying to limit the readers thinking to the given solution set. But what if there are other solutions the author doesn't present?
What's another solution? One that comes to my mind is to use Java's annotation feature. I am imagining an annotation you attach to each field in the object which declares the database column corresponding to the given field. A class-level annotation would declare the table to which the class corresponds. I can imagine this class could be autogenerated from the database without the programmer writing code. The only actual methods to write would be get/set methods. You could have a persistence library which introspects the class looking for those annotations centralizing the JDBC code to the library rather than spreading it among the database classes.
Seems pretty simple ... and it appears hibernate makes it even easier than that.
Of course using annotations requires JDK 5 (or later).
As simple as this approach might be to implement, it doesn't offer some flexibility Jack Herrington's article discusses. Namely, dynamically generating the object interface at runtime. I suppose that's even simpler, maybe. Certainly it lets the developer more quickly implement the code. But, I think this solution has problems of its own which Jack skips over.
The problem with a dynamically generated object interface is you don't know about any code mismatches until runtime. Meaning, you might not discover certain bugs in the code until the application is out in the field.
With Java you have compile time checking, and if some code refers to a field or method that's no longer there the program will fail to compile. That may seem burdensome but that's also A Good Thing. It tells the programmer up-front about a coding problem, letting the programmer more quickly fix it. It's well known that quickly identifying a bug makes it much less expensive to fix the bug than if the bug is identified out in the field (e.g. a program crash) and has to wend its way back through technical support and bug triage before it can be fixed.
With dynamically bound fields or methods ... okay, take this scenario in mind. Some code in the application refers to a field/method in a class. Then later there's a revamp of the code, a database table changes, some columns are deleted, and the class no longer has the matching fields or methods. Now, take your application that used that spiffy dynamic binding which made it a lot easier to do the initial implementation ... and what will happen. Will the programmers find all instances of references to those fields or methods?
I can almost gaurantee you the programmer won't. But the compiler would find them all -- that is, if the compiler were written to do compile time checking, like Java's is.
UPDATE: Apparently I missed this, but Jack says towards the end of the article the technique he presents isn't without its problems.