[
https://issues.apache.org/jira/browse/VELOCITY-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561224#action_12561224
]
Nathan Bubna commented on VELOCITY-582:
---------------------------------------
No sweat. Just glad you figured it out and that we don't have to fix this. :)
> Allow invocation of public methods in non-public classes
> --------------------------------------------------------
>
> Key: VELOCITY-582
> URL: https://issues.apache.org/jira/browse/VELOCITY-582
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.5
> Environment: Any
> Reporter: Andrew Swan
>
> I was tempted to log this as a bug, however according to this comment it's a
> feature:
> https://issues.apache.org/jira/browse/VELOCITY-214?focusedCommentId=12323932#action_12323932
> In any case, Velocity's requirement for all called methods to be in public
> classes forces developers to violate proper OO encapsulation by exposing
> implementation details. For example, consider this interface:
> public interface Foo {
> int getFooCount();
> }
> And a non-public implementation:
> class FooImpl implements Foo {
> public int getFooCount() {
> return 0;
> }
> }
> And a provider of Foo instances (in the same package as FooImpl):
> public class FooService {
> public Foo getFoo() {
> return new FooImpl(); // only this class should know what type of Foo
> is being created
> }
> }
> This is good OO code as it stands, however Velocity forces us to make FooImpl
> a public class. Although this allows Velocity to work properly, it also
> allows all other classes in the application to access the FooImpl class for
> themselves, creating the risk of excessive coupling and diluting the benefit
> of using interfaces in the first place.
> This wouldn't be so bad in a new project, but in my existing Velocity-based
> enterprise application of over 3000 classes, I can't be sure which of these
> can be properly non-public and which have to be made public just for
> Velocity's sake. In other words, there's no way to work out which ones might
> be (or might end up being) invoked by a template (particularly given that
> many of them are properly hidden behind interfaces). This means I'm not at
> liberty to refactor my code in the interests of proper encapsulation, because
> I run the risk of breaking a Velocity template. To me this is a big cross
> against Velocity, and if we weren't already using it heavily, I'd switch to
> an alternative templating tool. So any priority or importance that can be
> assigned to this issue would be greatly appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
