directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Class + Class Helper Pattern
Date Tue, 13 Feb 2007 17:28:10 GMT
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 :-)

(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:


Good thoughts.  Incidentally I have a 
"real world" experiment here in case anyone is

It's an Ecore2EcoreProcessor with an

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.

- Ole

--- David Saff <> 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.

- Ole

--- Michael Feathers <> 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 
> (  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


Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.

View raw message