[
https://issues.apache.org/jira/browse/VELOCITY-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Swan closed VELOCITY-582.
--------------------------------
Resolution: Invalid
Boy is my face red. One of the interfaces in my admittedly complex hierarchy of
interfaces wasn't marked as public. The Velocity template now works fine, even
under Velocity 1.4.
Sorry for the confusion; closing this issue as "Invalid".
> 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]
