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 20:46:23 GMT
Ole Ersoy wrote:
> Cool!
>
> I'm actually just using the ecore sample editor
> "Straight Up".
>
> I think GMF has other cool editors too, the sample
> ecore editor is a good lowest common denominator way
> of getting started.  You can also just annotate java
> interfaces.
>   
Have only explored some of this issues.  There is a lot of potential  here.
> If you do one of the emf library tutorials you'll see
> how it's used.
>
> http://www.eclipse.org/modeling/emf/docs/
>
> If you are using Eclipse Callisto, 
> just go to Help > Software Updates > Find Install >
> and get the EMF stuff.  This will put most of the
> tutorials in the Eclipse Help.
>
> Feel free to ask me questions at any point though.
>
> Once the Tuscany LDAP DAS gets done it will make going
> between EMF / SDO models and a ApacheDS really easy.
>   
Any time frames for the LDAP DAS?  Is there already a JDBC DAS? 
> It will pretty much be "Where to I want to store
> this...LDAP....Click....Done." :-).  So the entire
> TripleSec security model, the one I subversioned,  can
> be created in just one click in ApacheDS.  Then an
> editor could be generated for Eclipse, UI customized a
> little, and now there's a eclipse plugin for creating
> triplesec entries.
>
>   
Great.  I will want to see the editor it generates. 

On similar level of abstraction.  If you take a look at the SCA 
metadata  and from there go and look at the various XML metadata  
schemas for OSGi's service managers.  (There are a couple of standard 
ones and several new ones popping up -  like Spring-OSGi ) You will 
notice that all of these are,  just like the SCA,  trying to solve the 
same problem.  The xml could almost be identical. I recognized it 
immediately. 

Thus if you understand SCA you will also understand the SOA principles 
of OSGi. (The SOA at level 2 sits on top of the module/bundle/jar level 1.)
Have got to think Eclipse's SCA work is using this, but then again I 
don't really know.

At a certain point only the names change. The functional patterns are 
rather timeless. (so are the leaky abstractions.)
warm regards,
John
> Cheers,
> - Ole
>
> --- "John E. Conlon" <jconlon@verticon.com> wrote:
>
>   
>> 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
>>
>>     
> === message truncated ===
>
>
>
>  
> ____________________________________________________________________________________
> Now that's room service!  Choose from over 150,000 hotels
> in 45,000 destinations on Yahoo! Travel to find your fit.
> http://farechase.yahoo.com/promo-generic-14795097
>
>
>   


Mime
View raw message