Hashtable oriented programming
-
So I get a peek at this Java codebase I'll be working on, and I find all these classes implementing a BusinessObject interface, which has four methods: saveToDb(), loadFromDb(), isInDb(), and... getHashtable()...
Further inspection reveals the complete lack of getters or setters for any sort of bean-like properties...
That's right, these "classes" are all just shells around hashtables! All data storage appears to be done in the hashtable (which is a private field named the same as the class)... but you can stick any data you want into the hashtable:
Loan loan = new Loan();
loan.getHashtable().set("durationMonths", 36);
loan.getHashtable().set("amountDollars", 12500.00);
loan.getHashtable().set(42, "green eggs and spam"); // NO! NO!Also, even though these classes have data-access code in them (saveToDb() etc.), they don't know what table to save to unless you specify as such in the constructor! So you could conceivably create seventy bajillion different objects of the same class, each of which is to be saved to its own separate table, provided that said tables actually exist in the database!
And to top it all off, some of the classes implement isInDb() as follows:
- Execute "select 1 from theTableThatWeAreUsing"
- Does it return anything? Then return true! Otherwise return false.
Soooo... basically isInDb() returns true if the table contains ANY data whatsoever, rather than checking for the specific data in the object? I suppose this could be some sort of "singleton" table... but there doesn't seem to be any documentation saying as such!
-
First of all, you have no right to complain about anyone's code until you demonstrate proper use of whitespace and indentation.
Second, I did this once. It was a decent solution to the problem at hand (property-izing LDAP attributes), but it just didn't sit right with me. And as any creator who discovers he wrought amiss, I had to destroy my creation and start over.
Its dying screams still ring sweetly in my ears.
-
@hoodaticus said:
First of all, you have no right to complain about anyone's code until you demonstrate proper use of whitespace and indentation.
It's Community Server. I give him the benefit of the doubt.
@hoodaticus said:
Second, I did this once. It was a decent solution to the problem at hand (property-izing LDAP attributes), but it just didn't sit right with me.
I've also done it before, in some code that stored data in Amazon SimpleDB. I refactored it so it only generated the hashtables when absolutely necessary to feed the data back to Amazon, and the rest of the time it was in normal class properties.
Also worth noting that sometimes the *framework* does this, for example, getting URL params in ASP.net. But that's a case where I can't imagine how else they would have done it...
-
@blakeyrat said:
Also worth noting that sometimes the framework does this, for example, getting URL params in ASP.net. But that's a case where I can't imagine how else they would have done it...
They could dynamically build the type at runtime using Reflection.Emit. This would be TRWTF.
-
blakeyrat could be right -- the underlying datastore does not have to be a relational database. It makes perfect sense to me to store objects as hashtables in a object database. (The query for isindb is still a wtf though).
-
-
-
@dogbrags said:
the underlying datastore does not have to be a relational database.
It is a relational database, because it talks SQL (seen in the isInDb())
-
-
@dogbrags said:
It makes perfect sense to me to store objects as hashtables in a object database.
That would work fine for a primary key, but you need indexes too.
