On 11/18/2011 7:55, nemesis wrote:
> problem is that you're trying to make java look worse than it is

Well, it's the way this particular project at google was written. But yes, 
making Java functional without lambdas is messy.

I went thru something like 300 classes in this particular hugely 
overengineered project and didn't find a single noun in the bunch of them. 
They were all stuff like "CustomerUpdater" and "StorageManagerImplementor" 
and such.  I think it comes from doing too much networking, since networks 
don't do a real good job of shipping objects around. I've been trying to 
introduce the team to the wonders of actually having the code and the data 
in the same class. :-)

> var z = from y select z where z.id = myID
>
> in it would be something like:
>
> List<OrganizationIndividualRelationshipEntity> y, z;
> for (OrganizationIndividualRelationshipEntity x : y)
> if (x.id = myID) z.add(x);

Yep.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

Le 19/11/2011 07:07, Darren New nous fit lire :
> I've been trying to introduce the team to the wonders of actually having
> the code and the data in the same class. :-)

Well, from the old relational database experience... they shouldn't.
At least, they shouldn't be too tighly coupled until the code is
specific to the data and the data are usable only by the code.

Have a SQL schema (data) and only stored procedures usually ends up in
nightmare.

Data should have their invariants and rules.
Code should be in charge of transforming the data with respect to the
rules and adding new pieces of data which also match the rules.

But you're right, having data in very distant classes from the ones
which have the code is also a PITA. (and from an isolation point of
view, the code classes should not be friend of data class, so no ugly
shortcuts...)

Post a reply to this message

On 11/19/2011 1:33, Le_Forgeron wrote:
> Le 19/11/2011 07:07, Darren New nous fit lire :
>> I've been trying to introduce the team to the wonders of actually having
>> the code and the data in the same class. :-)
>
> Well, from the old relational database experience... they shouldn't.
> At least, they shouldn't be too tighly coupled until the code is
> specific to the data and the data are usable only by the code.

Well, the data in the database shouldn't be exposed to the user at all, any 
more than if your web site is stored in a database the browser should need 
to know that.

What I'm saying is that if you have a routine that (for example) marks a 
video as having been watched by the current user, it shouldn't be in some 
third class called "VideoWatcherRecorder" taking an integer video number and 
a long user ID. It should be in the video class and take a reference to a 
user object, or vice versa. Otherwise, you're just writing procedural code 
in Java.

> Data should have their invariants and rules.

Yep. And that's very hard to do without doing OO programming. Or relational 
programming. And if you're using an OO language like Java, it should be 
enforced in the objects that interface to the database (along with the 
database, if possible, which it isn't in this case).

> Code should be in charge of transforming the data with respect to the
> rules and adding new pieces of data which also match the rules.

Sure. But the difference is where that code live. Is it in some other 
package or compilation unit, or is it in the same class that reads and 
writes the database?

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message