왜 추상적인 필드를 사용하지 않는가?

왜 추상적인 필드를 사용하지 않는가?

Java 클래스는 왜 추상 메서드에서와 같은 추상 필드를 가질 수 없습니까?

예를 들어 다음과 같습니다.동일한 추상 기본 클래스를 확장하는 클래스가 두 개 있습니다.이들 2개의 클래스에는 각각 동일한 메서드가 있습니다.단, 스트링 상수는 에러 메시지입니다.필드가 추상적일 수 있다면 이 상수 추상화 방법을 기본 클래스로 끌어올릴 수 있습니다.대신, 저는 추상적인 방법을 만들어야 합니다.getErrMsg()이 경우 String을 반환하고 파생된2개의 클래스에서 이 메서드를 덮어쓰면 메서드를 풀업할 수 있습니다(이 메서드는 현재 추상 메서드를 호출합니다).

왜 처음부터 이 분야를 추상화하지 못했을까요?Java가 이를 허용하도록 설계되었을까요?

추상 클래스의 최종 필드가 생성자(테스트되지 않은 코드)에 초기화되어 있으면 설명한 작업을 수행할 수 있습니다.

abstract class Base {

    final String errMsg;

    Base(String msg) {
        errMsg = msg;
    }

    abstract String doSomething();
}

class Sub extends Base {

    Sub() {
        super("Sub message");
    }

    String doSomething() {

        return errMsg + " from something";
    }
}

자녀 클래스가 슈퍼 컨스트럭터를 통해 파이널 초기화를 "포기"하면 컴파일러는 이를 제공합니다. 경고. 추상적인 방법이 구현되지 않은 경우와 같은 오류입니다.

난 그게 의미가 없다고 생각해.함수를 추상 클래스로 이동하고 일부 보호 필드를 재정의할 수 있습니다.이것이 상수와 함께 작동하는지는 모르겠지만 효과는 동일합니다.

public abstract class Abstract {
    protected String errorMsg = "";

    public String getErrMsg() {
        return this.errorMsg;
    }
}

public class Foo extends Abstract {
    public Foo() {
       this.errorMsg = "Foo";
    }

}

public class Bar extends Abstract {
    public Bar() {
       this.errorMsg = "Bar";
    }
}

즉, 구현/덮어쓰기/무엇을 실시해야 한다는 것입니다.errorMsg아류에서요?나는 당신이 단지 기본 수업에서 그 방법을 가지고 싶어하고 그 때는 필드를 어떻게 다루어야 할지 몰랐다고 생각했다.

물론 이 기능을 사용할 수 있도록 설계되었을 수도 있지만, 이 기능을 사용하려면 여전히 동적 디스패치를 수행해야 하며, 따라서 메서드 호출이 필요합니다.자바의 디자인은 (적어도 초창기에는) 어느 정도 미니멀리즘적이기 위한 시도였다.즉, 설계자는 언어의 다른 기능으로 쉽게 시뮬레이트할 수 있다면 새로운 기능을 추가하는 것을 피하려고 했습니다.

당신의 제목을 읽었을 때, 추상적인 인스턴스 멤버를 말하는 것 같아서 별로 쓸모가 없었습니다.하지만 추상적인 정적 구성원은 완전히 다른 문제이다.

자바에서 다음과 같은 방법을 선언할 수 있으면 좋겠다고 생각했습니다.

public abstract class MyClass {

    public static abstract MyClass createInstance();

    // more stuff...

}

기본적으로는, 부모 클래스의 구체적인 실장은, 특정의 시그니처를 가지는 정적인 공장 방식을 제공한다고 주장하고 싶다. 하면 구체적인 에서 '아주 좋다'를 할 수 .Class.forName()그리고 내가 선택한 컨벤션에서 하나를 만들 수 있다는 것을 확신하라.

다른 옵션은 필드를 기본 클래스에서 퍼블릭(최종인 경우)으로 정의한 다음 현재 사용 중인 하위 클래스에 따라 기본 클래스의 생성자에서 해당 필드를 초기화하는 것입니다.순환 의존성을 도입한다는 점에서 좀 애매합니다.할 수 서브클래스는 하지 않지만 의 메서드나 가 어, 어, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, can, , can, can, field.

public abstract class Base {
  public final int field;
  public Base() {
    if (this instanceof SubClassOne) {
      field = 1;
    } else if (this instanceof SubClassTwo) {
      field = 2;
    } else {
      // assertion, thrown exception, set to -1, whatever you want to do 
      // to trigger an error
      field = -1;
    }
  }
}

언급URL : https://stackoverflow.com/questions/2211002/why-not-abstract-fields