Re: [TDD] Examples of Pojo Free Code?
|
Adam - thanks for taking the time to reply. I showed this email to the person who had been making the comments and all of a sudden this isn't what he thinks he had been saying :-) I've never heard that before have you?
Your advice and comments are overall sound. ORMs still bug me to a fair degree:
- You have real classes with behaviour, a null constructor and setter's - ugh I hate setters they get misused by accident, people call them innocently and then all of sudden you have a class who's data is in an odd state and you've no idea when/how it happened
- You wrap the Data Class in a Real class - avoiding the setter problem but relying on the convention that everyone remembers and never has enough discipline never to access the Data Objects.
I would have more respect for an ORM that doesn't require setters, JPA (never used by me) seems closer to the mark than Hibernate (which I have used).
Avi - in quoting the original person I think I misquoted POJO point.
All thanks for the comments, insightful as usual. One last thing I would love to see an open source project that persists objects to a Database that you think does the job well, cleanly, effectively. My goal is to have a shining example of good code for the client when I next back in their neck of the woods.
Cheers Mark
On Fri, Apr 11, 2014 at 4:20 PM, Adam Sroka <adam.sroka@...> wrote:
?
There's nothing about the ORM that forces them to use data classes. The framework typically requires you to follow some conventions and/or configure some options so that it knows how to match types. Also, you typically have to provide a no-arg constructor so that it can instantiate objects for you. Otherwise, they call them "plain old java objects" for a reason. They can and should have behavior.?
My advice would be the same as for any heavy framework use:
1) YAGNI?? 2) Test-drive a wrapper around the framework APIs you intend to use so that you can reference them directly in only a couple of places. It blows my mind why more people don't do this.?
3) Use a gradual changeover or parallel change strategy to move current uses of the framework to the new wrapper. This could take months or years to fully complete depending on how large and complex the legacy code is. Prioritize new functionality and/or areas that have caused you difficulty in the past.?
Beyond that, it sounds like there is a interesting cultural/educational problem. I would want to investigate to understand why they believe something that is clearly false: ORMs force them to write poorly factored and/or non-OO code. This is simply not the case. For example, Industrial Logic uses Hibernate in their eLearning product code (written in Java) and there are plenty examples of well factored classes in there.?
I have also run into a tendency to:
?a) copy contrived examples from the ORM documentation that needlessly couple you to the framework then blame the framework.?
b) misinterpret some design book as suggesting these are ORM "best practices." For example, Domain Driven Design, by Eric Evans, seems to be misinterpreted as saying that persistent "Entities" are just data and "Services" operate on that data. He describes both of these patterns but never says that they should be implemented that way.?
If you convince yourself that all the behavior belongs in static services (libraries) and all the data belongs in data classes (structs) then you should really be writing in C. That's not a knock on C. I love C. Java was designed for a different paradigm, though, and if you are going to work with it professionally you should know what that is.?
-- |
Mark Levison?| 1 (877) 248-8277 |??|??|?
Certified ScrumMaster Training:??|??|??|??|?
?|?
Proud Sponsor of??and? |
|
