Re: Examples of Pojo Free Code?

Mark Levison <[email protected]> Mon, 14 Apr 2014 10:52:47 -0400
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <CA+UdPQ8N1qd_1rfnCD4jRDarUT5mqd-jta62JO=fJxgyAoDKkQ@mail.gmail.com>
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:


   1. 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
   2. 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 <[email protected]> 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.
>
>
> On Fri, Apr 11, 2014 at 10:50 AM, Mark Levison <[email protected]> wrote:
>
>>
>>
>> I'm running an Agile Development course with some wonderful people at a
>> client who're addicted to their existing ORM. We've been discussing the
>> evil involved in Data Classes (i.e. classes with no behaviour). In their
>> world the habit of creating data classes comes from the fact that their ORM
>> (Hibernate and JPA) creates POJO type objects and they manipulate them.
>> They get the problem but would live to see an example of project that
>> doesn't do this.
>>
>> Do you know an OpenSource project that doesn't a use POJOs to get its
>> data in/out of an RDBMS? Do you know an ORM that helps people avoid
>> creating Data Classes?
>>
>> BTW I'm asking on this list lacking a better place.
>>
>> Cheers
>> Mark
>>
>>
>> --
>> [image: headshot-square-300x300]<http://www.flickr.com/photos/36331075@N00/9674877046/> *Mark
>> Levison* | 1 (877) 248-8277 | Twitter <https://twitter.com/mlevison> |
>> LinkedIn <http://ca.linkedin.com/in/marklevison> | Facebook<https://www.facebook.com/agilepainrelief>
>> Certified ScrumMaster Training: Vancouver<http://agilepainrelief.com/courses/vancouver>
>>  | Edmonton <http://agilepainrelief.com/courses/edmonton> | Ottawa<http://agilepainrelief.com/courses/ottawa>
>>  | Montreal <http://agilepainrelief.com/courses/montreal> | Toronto<http://agilepainrelief.com/courses/toronto>
>> Agile Pain Relief Consulting <http://agilepainrelief.com/> | Notes from
>> a Tool User <http://agilepainrelief.com/notesfromatooluser>
>> Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> and Agile
>> Coach Camp Canada <http://agilecoachcampcanada.wordpress.com/>
>>
>>
>  
>



-- 
[image: headshot-square-300x300]<http://www.flickr.com/photos/36331075@N00/9674877046/>
*Mark
Levison* | 1 (877) 248-8277 | Twitter <https://twitter.com/mlevison> |
LinkedIn <http://ca.linkedin.com/in/marklevison> |
Facebook<https://www.facebook.com/agilepainrelief>
Certified ScrumMaster Training:
Vancouver<http://agilepainrelief.com/courses/vancouver>
 | Edmonton <http://agilepainrelief.com/courses/edmonton> |
Ottawa<http://agilepainrelief.com/courses/ottawa>
 | Montreal <http://agilepainrelief.com/courses/montreal> |
Toronto<http://agilepainrelief.com/courses/toronto>
Agile Pain Relief Consulting <http://agilepainrelief.com/> | Notes from a
Tool User <http://agilepainrelief.com/notesfromatooluser>
Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> and Agile
Coach Camp Canada <http://agilecoachcampcanada.wordpress.com/>