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]

Reply via email to