Re: Examples of Pojo Free Code?

Adam Sroka <[email protected]> Mon, 14 Apr 2014 12:48:24 -0700
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <CALaPUVcp9jF-T-Zyc9e1A06+gAB_mvnDvK_2fYhs8BNO=0V_sQ@mail.gmail.com>
Units of discipline is an interesting way to look at it. I suppose that is
analogous to velocity or capacity. The way I look at it is more from a
learning perspective. You give people a whole bunch of new situations to
look for and new ways that they are supposed to respond and they'll either
freeze up or go back to the way they are used to doing it. You give them
one or two techniques or ideas and let them practice and rather quickly
they'll be hungry for more.

What I tend to do when I first get access to a client's code is go over it
to try to understand it and look for smells along the way. Once I have
identified a handful or so I will prioritize them by what seems either most
egregious or most prevalent/widespread. I will point out one or two (I used
to start with three, now I tend to start with two.) I will also ask
questions about anything that seems unusually confusing or out of place.

The first time around I usually just provide the information and see what
they do with it. Sometimes they fire back a lot of follow up questions,
sometimes they get defensive, and sometimes they just proactively start
looking for the smells themselves or even removing them. Each of those
reactions is a situation that can be coached, but each requires a slightly
different strategy to get through.




On Mon, Apr 14, 2014 at 10:03 AM, Mark Levison <[email protected]> wrote:

>
>
> George - we agree. Here's how I think of discipline. Most people have only
> 80-100 units at one time, asking them not to use Setter's or Classes that
> Eclipse helpful pops up might cost 10 units. I would rather use those 10
> units on practicing TDD without outside help in the months after taking a
> course from me :-)
>
> If it helps George many people don't realize how unique you're - you might
> have 250 units of discipline at one time. However your world is not the
> world of others.
>
> Cheers
> Mark
>
>
> On Mon, Apr 14, 2014 at 12:48 PM, George Dinwiddie <
> [email protected]> wrote:
>
>>
>>
>> Mark,
>>
>>
>> On 4/14/14, 10:56 AM, Mark Levison wrote:
>> >
>> >
>> > George - thanks (BTW with Ron you seem to be the person I know of the
>> > most mailing lists - we need to get you some more work :-)
>>
>> :-) I put in long hours. I do have some availability starting late May.
>>
>>
>> > I think I touched on your wrapper approach in my previous email. Like
>> > you I have used it in the past as an approach but it requires additional
>> > discipline from the dev team. Scrum already tries their discipline and I
>> > wish to conserve its use :-)
>>
>> All successful programming requires discipline. I've found that TDD
>> makes the discipline easy, combining it with ease of work and peace of
>> mind.
>>
>> - George
>>
>>
>> >
>> > Danke
>> > Mark
>> >
>> >
>> > On Sat, Apr 12, 2014 at 1:38 PM, George Dinwiddie
>> > <[email protected] <mailto:[email protected]>> wrote:
>> >
>> > __
>>
>> >
>> > Mark,
>> >
>> >
>> >
>> > On 4/11/14, 1:50 PM, Mark Levison 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?
>> >
>> > I don't have any examples to show, but a pattern I've used successfully
>> > is to encapsulate the "data object" within a business domain object.
>> > Typically I've used the data object as a parameter to the domain object
>> > consctructor, and provided a getter for when (if) I needed to recover
>> > the primitive for some reason. Often the user (ORM in this case)
>> > doesn't
>> > actually need a data-only object, anyway. It just needs some
>> > bean-pattern getters and setters for the fields it's to understand.
>> >
>> > - George
>> >
>> > --
>> > ----------------------------------------------------------
>> > * George Dinwiddie * http://blog.gdinwiddie.com
>> > Software Development http://www.idiacomputing.com
>> > Consultant and Coach http://www.agilemaryland.org
>> > ----------------------------------------------------------
>> >
>> >
>> >
>> >
>> > --
>> > 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/>
>>
>> >
>> >
>> >
>> >
>>
>> --
>> ----------------------------------------------------------
>> * George Dinwiddie * http://blog.gdinwiddie.com
>> Software Development http://www.idiacomputing.com
>> Consultant and Coach http://www.agilemaryland.org
>> ----------------------------------------------------------
>>
>>
>
>
> --
> [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/>
>
>  
>