Java에서 적용 가능한 경우 항상 "최종" 수식자 사용
Java에서는 모든 변수(로컬 또는 클래스), 파라미터 final(실제로 존재하는 경우)을 선언하는 관행이 있습니다.
이것은 코드를 훨씬 더 상세하게 만들지만, 이것은 코드를 쉽게 읽거나 움켜쥐는데 도움이 되며, 또한 의도가 명확하게 표시되므로 실수를 방지한다.
이에 대한 당신의 생각은 무엇이며, 당신은 무엇을 따를 것인가?
다음 사항에 대한 집착:
- Final 필드 - 필드를 final로 표시하면 필드 참조가 변경되지 않고 건설이 끝날 때까지 설정됩니다.이를 통해 필드를 안전하게 게시할 수 있으며 이후 읽을 때 동기화할 필요가 없습니다.(오브젝트 참조의 경우 필드 참조만 불변합니다.오브젝트 참조가 참조하는 것은 계속 변경될 수 있으며 불변성에 영향을 미칩니다).
- 최종 정적 필드 - 정적 최종 필드를 사용하던 대부분의 경우 에넘을 사용합니다.
고려하되 신중하게 사용하십시오.
- 파이널 클래스 - 프레임워크/API 설계만이 검토 대상입니다.
- 최종 방법 - 기본적으로 최종 수업과 동일합니다.crazy 및 marking themple final과 같은 템플릿 방식 패턴을 사용하는 경우, 상속에는 너무 많이 의존하며 위임에는 충분하지 않을 수 있습니다.
항문이 느껴지지 않는 한 무시하십시오.
- 메서드 파라미터와 로컬 변수 - 저는 게으르고 코드가 복잡하기 때문에 이 작업을 거의 하지 않습니다.수정하지 않을 파라미터 및 로컬 변수 마킹이 "더 큼"임을 완전히 인정합니다.디폴트였으면 좋겠어요.하지만 그렇지 않고 기말고사까지 겹치면서 코드를 이해하기가 더 어려워.내가 다른 사람의 코드에 있다면, 나는 그들을 끌어내지 않을 것이다. 하지만 만약 내가 새로운 코드를 쓰고 있다면, 나는 그들을 넣지 않을 것이다.한 가지 예외는 익명의 내부 클래스 내에서 액세스할 수 있도록 최종 표시를 해야 하는 경우입니다.
좋은 코딩 스타일과 관련이 있는 것 같아요.좋은 수 .final…
" " " final변경되어서는 안 되는 모든 것에 대해서, 단지 당신(또는 코드로 작업하고 있는 다음의 프로그래머)이 코드의 원인이 된 사고 프로세스를 잘못 해석하거나 오용하는 가능성을 좁힐 뿐입니다.적어도 그들이 당신의 예전 불변의 것을 바꾸고 싶어할 때 그것은 몇 가지 벨을 울릴 것이다.
처음에는 좀 어색해 보이기도 하고final코드에 키워드가 포함되어 있지만, 머지않아 단어 자체를 눈치채지 않게 되어, 「that-thing-will-never-change-from this-point-on」이라고 간단하게 생각할 수 있습니다(내 말을 믿어도 좋습니다).
★★★★★★★★★★★★★★★★★★★★★★★★★★★, 할 수 때, 뭔가에 을 붙이는 가 있을 때.final제가 하죠.
최종 키워드를 사용하기 전에 반드시 완전한 사용법을 이해해야 합니다.변수, 필드, 메서드 및 클래스에 적용할 수 있으며, 이에 따라 다른 영향을 미칩니다.
자세한 내용은 아래 링크 기사를 확인해 보시기 바랍니다.
final특히 변수의 경우 수정자는 컴파일러가 일반적으로 합리적인 규칙을 적용하도록 하는 수단입니다. 즉, (로컬 또는 인스턴스) 변수가 정확히 한 번 할당되도록 합니다(더 이상 할당되지 않음).되어 있는지 되는 변수와 같은 수 .NullPointerException:
final FileInputStream in;
if(test)
in = new FileInputStream("foo.txt");
else
System.out.println("test failed");
in.read(); // Compiler error because variable 'in' might be unassigned
변수가 여러 번 할당되지 않도록 함으로써 오버브로드 범위를 사용하지 않도록 할 수 있습니다.이것 대신:
String msg = null;
for(int i = 0; i < 10; i++) {
msg = "We are at position " + i;
System.out.println(msg);
}
msg = null;
다음을 사용하는 것이 좋습니다.
for(int i = 0; i < 10; i++) {
final String msg = "We are at position " + i;
System.out.println(msg);
}
일부 링크:
를 선언하는 것에 final여기에는 메서드 파라미터, 로컬 변수 및 드물게 값 오브젝트 필드가 포함됩니다.모든 곳에 최종 변수를 선언하는 데는 세 가지 주요 이유가 있습니다.
- 의도 선언:최종 변수를 선언하는 것은 이 변수가 한 번만 쓰여지는 것을 의미합니다.이것은 다른 개발자들에게는 미묘한 힌트이며 컴파일러에게는 큰 힌트입니다.
- 일회용 변수 적용:나는 각 변수가 삶에서 오직 하나의 목적만을 가져야 한다는 생각을 믿는다.각 변수에 1개의 목적만 부여함으로써 디버깅 중에 특정 변수의 목적을 파악하는 데 걸리는 시간을 단축할 수 있습니다.
- 최적화 가능:컴파일러가 성능 향상 기술을 가지고 있었다는 것은 알고 있습니다.이것은 특히 변수 참조의 불변성에 의존합니다.이러한 오래된 퍼포먼스 트릭(또는 새로운 트릭) 중 일부가 컴파일러에 의해 사용될 것이라고 생각합니다.
그러나 최종 클래스 및 방법은 최종 변수 참조만큼 유용하지 않다고 생각합니다.final키워드를 이러한 선언과 함께 사용하면 자동 테스트 및 코드 사용에 대한 장애물을 전혀 예상하지 못한 방법으로 제공할 수 있습니다.
유효한 Java에는 "Favors 불변의 객체"라는 항목이 있습니다.필드를 최종으로 선언하는 것은 이를 위한 몇 가지 작은 단계를 밟는 데 도움이 되지만, 물론 실제로 불변의 객체에는 그보다 훨씬 더 많은 것이 있습니다.
오브젝트는 불변성이라는 것을 알면 동기 걱정 없이 많은 스레드/클라이언트 간에 읽을 수 있으며 프로그램 실행 방법을 쉽게 추측할 수 있습니다.
변수에 대한 최종 키워드를 가지고도 실수를 막을 수 있는 상황은 한 번도 없었기 때문에, 현재로서는 큰 시간 낭비라고 생각합니다.
(변수가 최종적인 것에 대해 구체적으로 지적하고 싶은 것처럼) 실제 이유가 없는 한, 코드를 읽기 어렵게 하기 때문에 사용하지 않는 것이 좋습니다.
그러나 코드 읽기가 어렵거나 쓰기가 더 길다고 생각되지 않는 경우에는 반드시 시도해 보십시오.
편집: 명확화(및 다운투표 재확인을 위한 시도)로서 상수를 최종으로 표시하지 말라는 것이 아니라 다음과 같은 작업을 하지 말라는 것입니다.
public String doSomething() {
final String first = someReallyComplicatedExpressionToGetTheString();
final String second = anotherReallyComplicatedExpressionToGetAnother();
return first+second;
}
그것은 코드를 읽기 어렵게 만들 뿐이다.
또한 최종적인 역할은 변수를 재할당하지 못하게 하는 것뿐입니다. 변수를 불변하게 하거나 하는 것은 아닙니다.
상수에는 항상 Final을 사용해야 합니다.변수를 정의하는 규칙이 복잡한 경우 단수명 변수(단일 방법 내)에도 유용합니다.
예를 들어 다음과 같습니다.
final int foo;
if (a)
foo = 1;
else if (b)
foo = 2;
else if (c)
foo = 3;
if (d) // Compile error: forgot the 'else'
foo = 4;
else
foo = -1;
최종 키워드를 사용하는 것에 반대하는 가장 큰 주장 중 하나는 "불필요하다"며 "공간을 낭비한다"는 것입니다.
여기서 많은 훌륭한 투고에서 지적된 바와 같이 "최종"의 많은 이점을 인정한다면, 나는 자바가 기본적으로 변수를 "최종"으로 만들고, 코더가 원한다면 "변수"로 표시해야 한다고 주장한다.
용 i i i i를 쓴다.final아트리뷰트
final키워드는 오브젝트 속성에서 사용되는 경우 가시성의 의미를 가집니다.기본적으로 컨스트럭터가 반환되기 전에 최종 객체 속성의 값을 설정합니다., 이 말은, 이 말을 , 이 말을 그대로 두겠습니다.this하여 "를 사용합니다.final모든 속성에서 오브젝트는 (Java 5 시멘틱스 하에서) 적절하게 구성되어야 하며, 불변하기 때문에 다른 스레드에 안전하게 게시될 수 있습니다.
불변의 물체는 단순한 스레드 안전이 아닙니다.또한 프로그램의 상태 변화에 대해 추론하는 것이 훨씬 쉬워집니다. 왜냐하면 변화할 수 있는 공간은 의도적으로, 그리고 일관되게 사용될 경우 변화해야 할 것들만 완전히 제한되기 때문입니다.
나도 가끔 최종적인 방법을 만들지만, 자주 하지는 않는다.나는 좀처럼 기말고사를 하지 않는다.저는 보통 할 필요가 거의 없기 때문에 이것을 합니다.저는 상속을 잘 사용하지 않습니다.저는 인터페이스와 오브젝트 구성을 사용하는 것을 선호합니다.또한 테스트하기 쉬운 설계에 적합합니다.구체적인 클래스가 아닌 인터페이스로 코드화할 경우 jMock 등의 프레임워크를 사용하여 테스트할 때 상속을 사용할 필요가 없습니다.이는 구체적인 클래스에서보다 인터페이스를 사용하여 모의 객체를 만드는 것이 훨씬 더 쉽습니다.
수업의 대부분을 기말고사로 만들어야 할 것 같은데, 아직 본론으로 들어가지 않았을 뿐이야.
나는 내 일을 위해 많은 코드를 읽어야 한다.인스턴스 변수에서 최종 결과를 놓치는 것은 나를 짜증나게 하는 가장 중요한 일 중 하나이며 코드를 이해하는 것을 불필요하게 어렵게 만든다.내 생각에는, 지역 변수들에 대한 최종 결정은 명확성보다는 혼란을 야기한다.언어는 그것을 디폴트로 하도록 설계되었어야 했지만, 우리는 그 실수를 감수해야 한다.이 방법은 루프나 if-else 트리의 명확한 할당에 도움이 될 수 있지만, 대부분 방법이 너무 복잡하다는 것을 나타내는 경향이 있습니다.
final은 상수 및 불변성을 적용하기 위해 사용되어야 하지만 방법에는 또 다른 중요한 용도가 있습니다.
유효한 Java는 이 항목(항목 15)에 의도하지 않은 상속의 함정을 설명하는 전체 항목이 있습니다.실질적으로 상속을 위해 클래스를 설계하고 문서화하지 않은 경우 클래스에서 상속하면 예기치 않은 문제가 발생할 수 있습니다(항목은 좋은 예를 제시함).따라서 상속이 의도되지 않은 클래스 및/또는 메서드에 대해 final을 사용하는 것이 좋습니다.
그것은 엄격해 보일지 모르지만, 일리가 있다.다른 사용자가 사용하기 위해 클래스 라이브러리를 작성하는 경우, 해당 라이브러리를 위해 설계되지 않은 것으로부터 상속하는 것을 원하지 않습니다.백 호환성을 위해 클래스의 특정 구현에 자신을 구속합니다.팀에서 코딩하는 경우 팀의 다른 멤버가 결승에서 탈락하는 것을 막을 수 있는 것은 없습니다.하지만 이 키워드는 그들이 무엇을 하고 있는지 생각하게 하고, 그들이 물려받은 수업은 그것을 위해 만들어진 것이 아니므로, 그들은 특별히 조심해야 한다고 경고한다.
또 다른 주의사항은 많은 사람들이 최종을 참조를 변경할 수 없다는 것이 아니라 인스턴스 변수의 내용을 변경할 수 없다는 의미로 혼동한다는 것입니다.
지역 변수라도 최종 선언된 것으로 알고 있으면 나중에 참조가 변경될 염려가 없습니다.즉, 디버깅을 하고 나중에 해당 변수를 볼 때 동일한 개체를 참조하고 있음을 확신할 수 있습니다.그것이 버그를 찾을 때 제가 걱정할 필요가 있는 것 중 하나입니다.보너스는 변수의 99%가 최종으로 선언되면 실제 변수인 몇 가지 변수가 더 잘 눈에 띈다는 것입니다.또한, 마지막은 컴파일러가 그렇지 않으면 간과될 수 있는 더 많은 바보 같은 실수를 발견할 수 있도록 합니다.
「 」를 합니다.final각 방법의 각 매개변수에 대해 코더와 코드 판독기 모두에게 매우 많은 자극을 발생시킵니다.
자극이 합리적인 스위치를 넘어 기본적으로 인수가 최종인 Scala로 이동합니다.
또는 코드 스타일링 도구를 사용하여 자동으로 작업을 수행할 수도 있습니다.모든 IDE에는 또는 플러그인으로 구현되어 있습니다.
Java 변수와 함께 Final을 사용하면 C++ 상수를 대체할 수 있습니다.따라서 변수에 final과 static을 사용하면 변수는 불변합니다.동시에 이행한 C++ 프로그래머도 매우 만족합니다;-)
참조 변수와 함께 사용하면 개체를 조작할 수 있지만 개체를 다시 참조할 수 없습니다.
final을 메서드와 함께 사용하는 경우 메서드를 서브클래스에 의해 덮어쓸 수 없습니다.
사용법이 명확해지면 주의해서 사용해야 합니다.최종 방법을 사용하는 것은 다형성에 도움이 되지 않기 때문에 주로 설계에 따라 달라집니다.
변수의 값이 변경되거나 변경되어서는 안 된다고 확신할 때에만 사용해야 합니다.또한 SUN에서 권장하는 코딩 규칙을 따르십시오. 예: final int COLOR_RED = 1;(대소문자는 밑줄로 구분됨)
참조 변수에서는 특정 개체에 대한 불변의 참조가 필요한 경우에만 사용하십시오.
가독성 부분에 관해서는 최종 수식어를 사용할 때 코멘트가 매우 중요한 역할을 한다.
지역 변수에는 절대 사용하지 않습니다. 장황함을 더하는 것은 별 의미가 없습니다.변수를 재할당해야 한다고 생각하지 않더라도, 다른 생각을 하는 코드를 변경하는 다음 사람에게 거의 차이가 없습니다.또, 코드가 변경되고 있기 때문에, 이 변수를 최종화하는 본래의 목적은 무효가 될 수도 있습니다.명료함을 위해서라면, 장황함의 부정적인 효과 때문에 실패했다고 생각합니다.
멤버 변수에도 거의 동일하게 적용됩니다.이는 상수의 경우를 제외하고 거의 이점을 제공하지 않기 때문입니다.
또한 불변의 가장 좋은 지표는 그것이 그렇게 문서화되어 있거나 오브젝트를 변경할 수 있는 방법이 없기 때문에 불변의 가능성을 보증하는 유일한 방법이다(이를 통해 클래스를 최종화하는 것이 불변의 가능성을 보장하는 유일한 방법입니다).
하지만 그건 내 생각일 뿐이야:-)
수정되지 않은 모든 필드 및 속성에 final을 추가하도록 이클립스를 설정했습니다.이 방법은 파일을 저장할 때 이러한 최종 수정자를 추가하는 Eclipse "저장 작업"을 사용하면 매우 효과적입니다.
강력히 추천합니다.
Eclipse Save Actions의 블로그 게시물을 확인하십시오.
논쟁은 필요없다고 생각합니다.대부분 그들은 읽기 능력을 해칠 뿐이다.인수 변수를 다시 할당하는 것은 너무 어리석기 때문에 나는 그것들이 상수로 취급될 수 있다는 것을 꽤 확신해야 한다.
Eclipse는 최종 빨간색으로 칠해져 있기 때문에 코드 내의 변수 선언을 쉽게 찾을 수 있으며, 이는 대부분의 경우 읽기 빌리티를 향상시킨다고 생각합니다.
나는 모든 변수가 최종적이어야 한다는 규칙을 적용하려고 한다. 그렇지 않을 극단적인 타당한 이유가 없다.초기화를 찾아서 그것이 끝이라고 확신해야 한다면 "What is this variable?" 질문에 대답하는 것이 훨씬 쉽습니다.
나는 사실 며칠 동안 최종적이지 않은 변수들에 대해 다소 긴장한다.머리에 칼을 꽂는 것과 부엌 서랍에 꽂는 것 사이의 괴리감이랄까...
최종 변수는 레이블 값을 표시하는 좋은 방법입니다.
비최종 변수는 버그가 발생하기 쉬운 알고리즘의 일부에 결합됩니다.
한 가지 좋은 점은 알고리즘에 대해 질문에서 변수를 사용하는 옵션이 대부분의 경우 메서드를 대신 쓰는 것으로, 일반적으로 코드가 크게 개선된다는 것입니다.
한동안 코드 작업을 하고 있고 틈날 때마다 기말고사를 치르고 있어요.잠시 동안 이 작업을 수행한 후(변수, 메서드 파라미터 및 클래스 속성의 경우), 변수의 90%(또는 그 이상)가 실제로 최종 변수라고 말할 수 있습니다.원하지 않을 때 변수를 수정하지 않는 것의 이점(이전에도 봤지만 때로는 괴롭습니다)은 코드의 추가 입력과 추가 "최종" 키워드에 대한 대가를 지불한다고 생각합니다.
그러나 언어를 설계한다면 다른 키워드에 의해 수정되지 않는 한 모든 변수를 최종화할 것입니다.
기말고사는 수업이나 방법에는 잘 쓰지 않아요.클래스가 유틸리티 클래스(프라이빗 컨스트럭터만 있어야 함)가 아닌 한 이 설계는 다소 복잡합니다.
Collections.unmodifyable도 사용합니다.수정할 수 없는 목록을 만들 수 있습니다.
이벤트 리스너 등에 익명 로컬클래스를 사용하는 것은 Java의 일반적인 패턴입니다.final 키워드의 가장 일반적인 용도는 범위 내의 변수에 짝수 청취자가 접근할 수 있도록 하는 것입니다.
그러나 코드에 많은 최종 스테이트먼트를 넣어야 하는 경우.그건 네가 뭔가 잘못하고 있다는 좋은 암시일 수도 있어.
위의 기사에는 다음과 같은 예가 기재되어 있습니다.
public void doSomething(int i, int j) {
final int n = i + j; // must be declared final
Comparator comp = new Comparator() {
public int compare(Object left, Object right) {
return n; // return copy of a local variable
}
};
}
내부 및 외부 방법의 상수에 사용합니다.
서브클래스가 지정된 메서드를 덮어쓰지 않을지 모르기 때문에 메서드에만 사용합니다.
지금까지 일부 인프라스트럭처 클래스에 대해서만 최종 클래스를 사용했습니다.
IntelliJ IDEA는 함수 파라미터가 함수 내부에 입력되면 경고합니다.function 인수에는 final 사용을 중지했습니다.Java Runtime 라이브러리에서도 볼 수 없습니다.
나는 사람들이 기말고사를 무시하도록 내버려두는 것을 좋아하기 때문에 방법이나 수업에서 기말고사를 거의 사용하지 않는다.
않으면 은 ★★★★★★★★★★★★★★★★★★★★★★★ VIP★ VISA일 입니다.public/private static final type SOME_CONSTANT;
클래스를 final로 표시하면 런타임 대신 컴파일 시 일부 메서드바인딩이 발생할 수도 있습니다.아래의 "v2.foo()"를 생각해 보십시오.컴파일러는 B가 서브클래스를 가질 수 없다는 것을 알고 있기 때문에 foo()를 덮어쓸 수 없기 때문에 호출할 구현이 컴파일 시에 인식됩니다.클래스 B가 최종 마크가 아닌 경우 v2의 실제 유형은 B를 확장하고 foo()를 덮어쓰는 클래스일 수 있습니다.
class A {
void foo() {
//do something
}
}
final class B extends A {
void foo() {
}
}
class Test {
public void t(A v1, B v2) {
v1.foo();
v2.foo();
}
}
상수에 final을 사용하는 것이 좋습니다.하지만, 나는 그것을 방법이나 수업에는 사용하지 않을 것이다. 왜냐하면 그것은 불가능하지는 않더라도 시험을 더 어렵게 만들기 때문이다.클래스 또는 메서드를 반드시 최종화할 필요가 있는 경우는, 이 클래스에서 몇개의 인터페이스를 실장하고 있는 것을 확인해 주세요.그러면, 같은 인터페이스를 실장하고 있는 모크를 가질 수 있습니다.
언급URL : https://stackoverflow.com/questions/137868/using-the-final-modifier-whenever-applicable-in-java
'source' 카테고리의 다른 글
| Vue 2.2.0으로 업데이트하는 중입니다. vue-template-compiler 및 vue-loader 버전이 일치하는지 확실하지 않습니다. (0) | 2022.07.27 |
|---|---|
| ":" (콜론) (C structure) - 무슨 뜻이죠? (0) | 2022.07.27 |
| vue에서 사용자 지정 클래스 인스턴스화 (0) | 2022.07.27 |
| Vue.js 응용 프로그램은 Gitlab 페이지에서 실행되지 않습니다. (0) | 2022.07.27 |
| Java에서 사용자 정의 예외 클래스를 정의하는 가장 쉬운 방법은 무엇입니까? (0) | 2022.07.27 |