directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Class + Class Helper Pattern
Date Tue, 13 Feb 2007 19:25:51 GMT
Hi Ole,

I think the EMF work your doing is just the kind of thing we need. 
What UML editor are you using for generating the ecore models?

cheers,
John

PS - On the other hand I am sorry I don't like the idea of 'all public 
methods for the sake of testing'.  See comments in Emmanuel's post.
Ole Ersoy wrote:
> Hey Guys,
>
> Just something for you to think about, because and I'm
> going to write it up in more detail in the unit
> testing topic of the Contributor Guide.
>
> If you end up looking at that ecore2ecore code just
> for fun :-)
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=173226
>
> (I'm soon checking this in to Subversion after I get
> the licensing headers, etc.)
>
> You'll notice that I used a 
> Class + ClassHelper pattern.
>
> So I can have all the methods public on the Helper,
> thus I could easily test them all.
>
> I asked others one the JUnit list if there are any
> security risks to having all public methods.
>
> They said not really.
>
> Here's a piece of the discussion that captures the
> essence of what will be in the contributor guide:
>
>
> ---------------------------------------------------
> David,
>
> Good thoughts.  Incidentally I have a 
> "real world" experiment here in case anyone is
> interested:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=173226
>
> It's an Ecore2EcoreProcessor with an
> Ecore2EcoreProcessorHelper
>
> that has all public methods. 
>
> This made it easy to test the solution, and hopefully
> just as easy to understand it for others.
>
> Some of the methods could have easily been private,
> but having them in the Helper make them a natural
> target for a Utility library when someone sees the
> case for it, making the code base smaller, more
> managable, and useful.
>
> This way Helper classes can be scanned by other
> developers looking for an approach when they see that
> the helper Target (The MainClass) does something that
> they are interested in.
>
> Cheers,
> - Ole
>
> --- David Saff <saff@mit.edu> wrote:
>
>   
>> Ole,
>>
>> It has been proposed in the past--I can't seem to
>> find it on Google,
>> but I have a memory of Ron Jeffries quoting someone
>> else who had done
>> a small experiment of making all methods public and
>> still having a
>> sensible API, and had liked the results.
>>
>> I myself am not tempted to go to this extreme. 
>> Private methods
>> generally mean that I have several abstraction
>> layers living within
>> the same class.  I'm not bothered by this in
>> principle, until I find
>> the "hidden" abstraction layer troublesome or
>> interesting enough that
>> I'm tempted to test it directly, in which case I
>> take the time to
>> think about the name and interface of that hidden
>> abstraction layer,
>> and expose it as a class.
>>
>>    David Saff
>>     
>
>
>
> ------------------------------------------------------
>
>
>
>
> ------------------------------------------------------
> Hey Michael,
>
> Yes I imagine some of use like having everything in
> one class.
>
> I personally like having really small classes, and I
> also like to have everything tested.  I anticipate
> there will be a lot of automatic test generation tools
> out there soon, and that these will fit well with code
> structured that way.
>
> I also find it valuable when someone says "Well we
> have to leave all that code untested because there's
> sooooo many private  methods".
>
> I either have to say "OK - Go to JUnit's site and find
> the how to test private methods reflector thingy" or
> use the Class, ClassHelper pattern.
>
> My personal feeling is leaving method "Simplicity"
> judgement up to the developer can lead to "Shortcuts"
> :-)
>
> I think it's easier if an entire team of developers
> agrees to a certain pattern.  That way we know how to
> look at other people's code.
>
> That said I'm also for having untested methods, as
> long as it is generated code.
>
> Since the code is generated, to me it means that the
> pattern that generated the code has already been
> tested, so that everything really is tested,  it's
> just that the test is tagged to the pattern and the
> code generation template.
>
> Cheers,
> - Ole
>
>
>
> --- Michael Feathers <mfeathers@mindspring.com> wrote:
>
>   
>> Ole,
>>
>> I don't know that there any security risks to that
>> approach.  
>> Ultimately, security is more about who has access to
>> your code rather 
>> than anything that you do to protect it; any runtime
>> can be fiddled with. 
>>
>> I would hesitate before using something like Class +
>> ClassHelper as an 
>> architectural style.  It would be a shame to have to
>> look at two things 
>> whenever you used to have to look at one. 
>>
>> To me, the better thing is to notice when things are
>> hard to test and 
>> then decide whether to break your classes down into
>> pieces where 
>> operations can be public and whether, once public,
>> they enable more in 
>> your code.  If you want to see an example of this,
>> look at FIT 
>> (fit.c2.com).  I don't recall if it's that way now,
>> but in the early 
>> versions all methods were either public or
>> package-scope.  You have to 
>> make some serious tradeoffs when you adopt that
>> style for API code, but 
>> in general it's a reasonable style for application
>> (non-API) code.
>>
>> Michael Feathers
>> www.objectmentor.com
>>     
>
> -----------------------------------------------------
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
>
>   


Mime
View raw message