Slashdot Mirror

So the more correct phrasing would be "Entity EJBs and Hibernate were both attempts to solve the object persistence problem."

Sort of. Hibernate also encourages the kind of approach you see in books like Domain-Driven Design, and in places where people talk about POJOs. That includes putting most of the business logic in the business objects. (Really, that's day one in an Object-Oriented Design class: object = data + behavior.) Ergo, a lot of the session bean shennanigans I have seen in EJB apps become unnecessary.

You're right that EJB's messaging stuff and some of the session stuff is untouched by Hibernate, and I more accurately could have said "most of EJB" in the places where I said "EJB". Given that that most people I've talked to picked up EJB to solve the persistence problem, this seems like a minor quibble to me, but I'm glad to take your word that this was worth thrashing out.

That's not what I meant, and it's a non-sequitor [sic] anyway. Hibernate uses CGLIB to do runtime optimization, which they admit provides a very minor improvement over the JVM's reflection API. [...] I fail to see what this has to do with either the end developer or with Ruby

That's not all they do. As one of the FAQs I linked you to mentions, to make a class persistent they dynamically create magic subclasses at runtime using CGLIB. This is because you can't write Hibernate in pure Java. (Don't believe me? Go try it.) Ruby on Rails, on the other hand, only requires Ruby because Ruby is a more powerful language. Sun's cathedral-style thinking means that we lose out on both the features that they should be stealing from other languages and the innovation those features enable.

And that's my main point here: a more open-source attitude would mean that Sun doesn't have to be years behind the curve, like they were with Hibernate and all of the stuff they stole from C#.

I've volunteered to create a recipe-wiki-site-thing for a friend, and coming from a background in C and SQL there was just too steep a curve to map a procedural train of thought and pre-planned SQL onto the Rails way of doing things.

For which, I salute you.

Personally, I'm a big OO guy; for anything beyond a thousand lines of code, I feel the object-oriented approach makes maintenance much, much easier.

But what makes me bat-shit crazy is people who feel like you do but aren't smart or independent enough to be honest that either a) they don't really get OO yet, or b) they get it but prefer to work otherwise. So they go and write a bunch of semi-procedural crap in an OO language, half-assedly using the various OO features wrongly. I've heard this called "procedural object oriented programming" or POOP, and it is so much worse than either good procedural code or good object-oriented code. And honestly, 75% of the Java code I get asked to review is POOP.

So I seriously and unironically salute you for knowing what works for you, and valuing good code over following the latest trends.

And a little P.S. to my fellow Java developers: If you have a lot of objects with data and no behavior (just getters and setters), or a bunch of objects with no data and lots of behavior, then that is not object-oriented programming. The first is a struct; the second is a function library. Object = data + behavior. If you aren't sure whether you're doing OO work, read Domain-Driven Design.

Ignore the analogies, OOP has nothing to do with obkects at its core. OOP is basicly encapsulation and interfaces.

A reasonable theory, but you're missing half of the power of object-oriented languages. Read Evans' fantastic book Domain-Driven Design for the other half. You will discover than a lot of people, even many of those writing "Intro to Java" books, made the transition to OO languages without ever learning OO design.

If you want code that can be readily understood you need something other than coding conventions. Coding conventions only make the code all look the same. You can get almost all of the benefit (without most of the arguments) by saying only that each file must be written with the same coding convention throughout. The code will get prettier and prettier with tighter conventions and developers will waste less time reformatting each others code. But it won't do a thing to make your project more understandable.

For that you need an understandable design and the best advice I've ever seen for that is in Eric Evens' "Domain Driven Design" http://domaindrivendesign.org/. The advice there will work for both Agile and non-Agile projects and its core themes are pretty much unavoidable truths about how to write code for a project that is also written about the project: use language that comes from the projects domain, insulate code from each domain or sub-domain from the rest of the world, keep each method at the same level of abstraction (that's big) and make implicit concepts explicit, to name a few. The key is for your developers to consider themselves to be authors and to strive to keep each little piece of code they write on-topic. Not only will it be easier for new developers to come up to speed but the code will work a heck of a lot better too.

I don't have a problem with most of these development methodologies perse, but most of them seem to lack the entire concept of DATA and INFORMATION.

You should check out things like Agile Modelling and Agile Data for more information. I don't think it's core to agile methods, as not every application uses a database. But if you're big into databases, these sites can help you see how agile approaches could work in your environment.

Do these methodologies include some prep work on gathering business requirements and understanding the underlying information relationships?

It's not just prep work; it is work that should happen all the time. That's why Refactoring and Domain-Driven Design are such a big deal to people doing Extreme Programming. We strive for representational harmony across all levels, from talking with users down to the database schema. And not just in the spec, either; as we learn more about the domain and find better representations, refactoring lets us safely change the structure of the code to match.

This is a good start, but there are a couple of ways to improve.

First, Java's serialization format is pretty opaque. That makes debugging, testing, and schema migration a pain in the ass. A better choice is XML via XStream. If you have a good object model, its output XML is pretty readable. And you can improve that by adding custom adapters for particular objects. And for the XML-is-too-verbose crowd, let me suggest putting a GZIPOutputStream in the chain.

You generally do have something like GameMap or MobileObjectsHashTable though.

This is a good approach in Perl, but in Java you can do better. When I see classes with names like that, it generally means the programmer is thinking too much about implementation and not enough about design. Instead of GameMap, it should be Game. Instead of passing in string keys and casting objects when you (hopefully) get the right ones out, take advantage of the language's static typing and put all that work inside of the Game object.

For more on this topic, read the excellent book Domain-Driven Design.

The best trick I've ever seen for setting project goals is to sit developers down with business users or the end users of the product and have them observe work in action. This understanding can go a long way when a developer is back in the 'cube' for long hours of coding. Domain knowledge is critical to a developer. Otherwise you end up with some trully epic program that bears little to no pracitcal value.

There's an even better trick: put your development team in a shared workspace. Then make a domain expert the product manager and put them in the same room, so that if developers have questions they just have to look up and raise their voice a bit.

It's fantastic. The closest we get to specs is whiteboard sketches and the occasional UI mockup. And that's all we need. The developers love it, because there's no guesswork involved. And the product manager loves it because he gets exactly what he wants without having to write phone-book-sized spec documents.

On the topic of knowing the domain, I also strongly recommend the book Domain-Driven Design. It's a brilliant book on how to base your OO model on the thing that is least likely to change: the business domain.