[jsword-devel] ActionFactory

[DM Smith]

I think that it is not a good idea to add complexity to the code when 
making the methods public is simpler and a comment can suffice to add 
the needed protection.

While a methods scope and signature give a lot of information about it, 
ultimately it is the documentation that gives the method's contract. 
Everything else the method does is an "undocumented behavior" and is not 
to be relied upon. If a user of the class does something else with the 
method, that's just too bad if it breaks later when the method is 
re-implemented.

Just my opinion:

I programmed in C++ for years and it is not an OO language (I am not 
intending to start a flame war), it merely was the C language with OO 
features added and many left out. Some of the features were clumsy (I am 
a compiler writer by schooling) and books were written on how to 
implement this or that missing OO feature.

What I found was that unless the addition were especially well written 
it made the code harder to maintain than adding judicious comments to 
the code as to why you were not doing it.

Ultimately that is why we migrated to a true OO language. We were always 
wanting more OO than what C++ provided.

Joe Walker wrote:
> 
> v. quickly, I'm on my way to work.
> inner classes that call private methods on their outer classes alter the 
> methods to be protected and include a parameter that only the inner 
> class could create, effectively making them a 'friend'.
> 
> Such a mechanism could work, but would probably be too complex, and not 
> very readable?
> 
> Joe.
> 
> DM Smith wrote:
> 
>> There are several different signatures of ActionPerformed.
>>
>> I think that this method can be put in ActionFactory:
>> public void actionPerformed(ActionEvent e, Object caller)
>>
>> I don't think that the code will have problems if the methods it calls 
>> via reflection are public. I had problems with the reflection before 
>> caller was added.
>>
>> As to whether they should be public, they should not be. But, we often 
>> have to do otherwise to improve the code in general. (Where is C++'s 
>> friend mechanism to limit collaborations when you need it!)
>>
>> Perhaps it would be best to put a general comment in the class files 
>> stating that it should be non public. I have seen many ways to do this 
>> on a per method basis:
>> /* non */ public void doit()
>> /* private */ public void doit()
>> ...
>>
>>
>>
>> Joe Walker wrote:
>>
>>>
>>> Hi,
>>>
>>> Is there any reason why we shouldn't promote the actionPerformed 
>>> method that is implemented many times in the children of 
>>> ActionFactory to ActionFactory itself?
>>>
>>> The only implication that I can see is that the methods called by 
>>> ActionFactory would need to be public and not protected, but this 
>>> would enable us to get rid of a far bit of code by using 
>>> ActionFactory directly.
>>>
>>> Or did I miss something?
>>>
>>> Joe.
>>>
>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
> 
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>