Собственные методы Java. Публичный и частный

Предположим, что нам нужно реализовать некоторый java-метод в собственном коде и выставить его пользователю. Мы знаем, что вся работа выполняется на родной стороне, т.е. Единственная ответственность java-кода - передать предоставленные пользователем аргументы в собственный код и вернуть результат обратно. В соответствии с этим, java-слой может быть реализован двумя способами:

  • Используя собственные методы, непосредственно связанные с пользователем:

    public native Object doSmth(Object arg0, Object arg1);

  • Используя тонкую публичную оболочку вокруг собственного собственного метода:

    public Object doSmth(Object arg0, Object arg1) {
    return nativeDoSmth(arg0, arg1);
}

private native Object nativeDoSmth(Object arg0, Object arg1);

Я видел оба подхода в реальных проектах и ​​даже в первых и последних в том же проекте.

Итак, мой вопрос: имеет ли какая-либо из упомянутых альтернатив какие-то технические или эксплуатационные или ремонтные преимущества, которые должны поощрять использование только одного варианта. Или, может быть, это всего лишь вопрос вкуса?

Ответы

Ответ 1

Итак, мой вопрос: есть ли какие-либо из упомянутых альтернатив? технических или эксплуатационных характеристик, а также рекомендуется использовать только один вариант.

Преимущество в области безопасности - вот ключ. Как указано в комментариях, объект раскрывает свое поведение. Как это реализовано, это не пользовательский бизнес. Это дает вам большую гибкость.

Предположим, что в будущем (см.: ремонтопригодность) вы обнаружите, что вам нужно/нужно настроить метод таким образом, чтобы он делал что-то до и/или после обычного вызова. В первом подходе вам нужно будет отказаться от метода и создать новый. Во втором втором подходе вы просто добавляете все, что вам нужно в методе, и пользователю все равно.

Что касается производительности, теоретически, первый подход быстрее, потому что это менее 1 вызов. На практике это совершенно ничтожно.

Ответ 2

Я думаю, что это в основном личный стиль. Если вы считаете следующий код:

rattias-macbookpro: tst rattias $diff Test1.cl Test1.class rattias-macbookpro: tst rattias $vi Test1.java

public class Test1 {
  public static void main(String[] args) {
    Test2 t = new Test2();
    t.m();
  }
}

public class Test2 {
  public native void m();
}

При компиляции это дает Test1.class, который идентичен тому, который создается, когда Test2 определяется следующим образом:

public class Test2 {
  public void m() {
  }
}

Это означает, что вы могли бы изменить реализацию, чтобы быть естественной, чистой java, чистой оболочкой java для собственного частного метода, в любой момент времени, не затрагивая пользователей. Может возникнуть вопрос о том, должна ли общая функция публичного API быть родной, а не только частью вычисления, но опять же, которую можно изменить в любой момент.