Реализовать интерфейс с конечными полями или полями доступа напрямую? - PullRequest
0 голосов
/ 17 декабря 2010

Есть ли преимущество в том, что НЕ имеет класс implement интерфейс и вместо этого напрямую использует конечные поля?Например:

public interface MyInterface {
    int CONST_A = 16;
    int CONST_B = 45;
}

Подход 1:

public class MyClass implements MyInterface {

    MyClass() {
        System.out.println("A = " + CONST_A);
        System.out.println("B = " + CONST_B);
    }

}

Подход 2:

public class MyClass {

    MyClass() {
        System.out.println("A = " + MyInterface.CONST_A);
        System.out.println("B = " + MyInterface.CONST_B);
    }

}

Мне было интересно, имеет ли какой-либо из вышеуказанных подходов какое-либо преимуществонад другим.Одно из мест, где эта ситуация возникает, - в Blackberry, где ваши локализованные тексты определены как интерфейс с ключами для строк, и вам необходимо вызвать системный API с ключом в качестве аргумента в различных частях кода.

Ответы [ 4 ]

4 голосов
/ 17 декабря 2010

Считается плохой практикой помещать константы в интерфейсы и реализовывать эти интерфейсы для доступа к константам. Причина в том, что многие классы могут реализовывать интерфейс, обеспечивая таким образом множество точек доступа для одних и тех же констант.

Итак, чтобы ответить на ваш вопрос, я бы лучше использовал второе решение. Более того, я бы поместил константы в последний класс, чтобы к константам была только одна точка доступа. Это было бы яснее, и было бы легче провести рефакторинг.

3 голосов
/ 17 декабря 2010

использовать перечисление для констант (Effective Java)

Например, определить так и вызвать KernelError.KE_UNDEFINED_CALLER

public enum KernelError {
    KE_NO_ERROR(0), KE_UNDEFINED_SESSION(1), KE_UNDEFINED_CALLER(2), KE_SESSION_EXPIRED(
            3), KE_NULL_VALUE_IN_SESSION(4), KE_N0_SUCH_METHOD(5);

    private KernelError(int errorCode) {
        setErrorCode(errorCode);

    }

    private int errorCode;

    /**
     * @return the errorCode
     */
    public int getErrorCode() {
        return errorCode;
    }

    /**
     * @param errorCode
     *            the errorCode to set
     */
    public void setErrorCode(int errorCode) {
        this.errorCode = errorCode;
    }

}
1 голос
/ 17 декабря 2010

Я предпочитаю подход 2, так как он не загрязняет пространство имен используемого класса всеми возможными константами. Это уменьшает количество вариантов завершения кода. Кроме того, при рассмотрении использования константы, квалифицированное имя делает очевидным, что это константа и где эта константа определена.

То есть я предпочитаю

interface Constants {
    static int A;
    static int B;
}

void foo() {
    System.out.println(Constants.A);
}

до

interface Constants {
    static int Const_A;
    static int Const_B;
}

void foo() {
    System.out.println(Const_A);
}
1 голос
/ 17 декабря 2010

Если вы определили константы в интерфейсах и, например, определите MyInterface2, который имеет константу CONST_A, они конфликтуют. Лично я думаю, что подход 2 легче читать.

...