C #과 Java가 왜 '=='의 기본값으로 참조 동등성을 사용합니까?

Java와 C # (및 다른 언어)이 기본적으로 동등성을 참조하는 이유를 잠시 고민해 왔습니다 ==.

내가하는 프로그래밍에서 (확실히 프로그래밍 문제의 작은 하위 집합 일뿐입니다), 참조 평등 대신 객체를 비교할 때 거의 항상 논리적 평등을 원합니다. 나는 왜 두 언어가 왜이 길을 거꾸로 돌리고 ==논리적 평등을 유지하고 .ReferenceEquals()참조 평등 을 위해 사용 하지 않는지를 생각하려고 노력했다 .

분명히 참조 평등을 사용하는 것은 구현하기가 매우 간단하고 매우 일관된 동작을 제공하지만 오늘날 내가 보는 대부분의 프로그래밍 방식과 잘 맞지 않는 것 같습니다.

논리적 비교를 구현하려는 문제를 무시하고 모든 클래스에서 구현해야한다는 것을 무시하고 싶지 않습니다. 또한 이러한 언어는 오래 전에 설계되었지만 일반적인 질문은 있음을 알고 있습니다.

내가 이것을 놓친 것에 대한 기본 설정의 주요 이점이 있습니까? 아니면 기본 동작이 논리적 평등이어야한다는 것이 합리적입니까, 그리고 참조 평등으로 다시 기본 설정하면 논리적 평등이 클래스에 존재하지 않습니다.

C #은 Java가했기 때문에 그렇게합니다. Java는 연산자 오버로드를 지원하지 않기 때문에 Java가 수행되었습니다. 각 클래스마다 값 평등을 재정의해야하므로 연산자가 아니라 메서드 여야합니다. IMO 이것은 잘못된 결정이었습니다. a == b보다 쓰기와 읽기가 훨씬 쉽고 a.equals(b)C 또는 C ++ 경험이있는 프로그래머에게는 훨씬 더 자연 스럽지만 a == b거의 항상 틀립니다. 필요한 ==곳 .equals을 사용하는 데 따른 버그는 수많은 프로그래머 시간을 낭비했습니다.

짧은 대답 : 일관성

그러나 귀하의 질문에 올바르게 대답하기 위해 한 걸음 물러서서 프로그래밍 언어에서 평등의 의미 에 대한 문제를 살펴 보는 것이 좋습니다 . 다양한 언어로 사용되는 적어도 세 가지 다른 가능성이 있습니다.

• 참조 평등 : a와 b가 같은 객체를 참조하면 a = b가 참임을 의미합니다. a와 b의 모든 속성이 동일하더라도 a와 b가 다른 객체를 참조하면 사실이 아닙니다.
• 얕은 동등성 : a와 b가 참조하는 객체의 모든 속성이 동일한 경우 a = b가 참임을 의미합니다. 두 객체를 나타내는 메모리 공간을 비트 단위로 비교하면 얕은 동등성을 쉽게 구현할 수 있습니다. 참조 평등은 얕은 평등을 의미합니다.
• 깊은 평등 : a와 b의 각 속성이 동일하거나 매우 같으면 a = b가 참임을 의미합니다. 깊은 평등은 참조 평등과 얕은 평등에 의해 암시됩니다. 이런 의미에서 깊은 평등은 가장 약한 형태의 평등이며 기준 평등은 가장 강합니다.

이 세 가지 유형의 평등은 구현하기 편리하기 때문에 자주 사용됩니다. 세 개의 평등 검사는 모두 컴파일러에 의해 쉽게 생성 될 수 있습니다 (심도 평등의 경우 컴파일러는 태그 비트를 사용하여 무한 루프를 방지해야합니다. 순환 참조가 있습니다). 그러나 또 다른 문제가 있습니다.이 중 어느 것도 적절하지 않을 수 있습니다.

사소한 시스템에서 객체의 평등은 종종 깊은 평등과 참조 평등 사이의 무언가로 정의됩니다. 특정 상황에서 두 객체를 동일한 것으로 간주할지 여부를 확인하기 위해 일부 속성은 메모리의 위치에 따라 다른 속성과 깊은 평등으로 비교해야하지만 일부 속성은 완전히 다른 것으로 허용 될 수 있습니다. 우리가 정말로 좋아하는 것은 종종 문학 의미 론적 평등 에서 불리는“제 4의 평등” 입니다. 우리의 영역에서 상황이 동일하면 동일합니다. =)

그래서 우리는 당신의 질문으로 돌아갈 수 있습니다 :

내가 이것을 놓친 것에 대한 기본 설정의 주요 이점이 있습니까? 아니면 기본 동작이 논리적 평등이어야한다는 것이 합리적입니까?

어떤 언어로든 'a == b'를 쓸 때 무엇을 의미합니까? 이상적으로는 항상 동일해야합니다. 의미 적 평등. 그러나 그것은 불가능합니다.

주요 고려 사항 중 하나는 적어도 숫자와 같은 간단한 유형의 경우 동일한 값을 지정한 후에 두 변수가 동일 할 것으로 예상합니다. 아래를보십시오 :

var a = 1;
var b = a;
if (a == b){
    ...
}
a = 3;
b = 3;
if (a == b) {
    ...
}

이 경우 두 진술에서 모두 'a는 b'입니다. 다른 것은 미쳤을 것입니다. 대부분의 언어는이 규칙을 따릅니다. 따라서 단순한 유형 (일명 값)을 사용하여 의미 적 평등을 달성하는 방법을 알고 있습니다. 객체를 사용하면 완전히 다를 수 있습니다. 아래를보십시오 :

var a = new Something(1);
var b = a;
if (a == b){
    ...
}
b = new Something(1);
a.DoSomething();
b.DoSomething();
if (a == b) {
    ...
}

우리는 첫 번째 'if'가 항상 사실이라고 기대합니다. 그러나 두 번째 'if'에서 무엇을 기대하십니까? 정말 달려 있습니다. 'DoSomething'이 a와 b의 (의미 적) 평등을 바꿀 수 있습니까?

시맨틱 평등의 문제점은 컴파일러가 객체에 대해 자동으로 생성 할 수 없으며 할당에서 분명하지 않다는 것 입니다. 사용자가 의미 적 동등성을 정의 할 수있는 메커니즘이 제공되어야합니다. 객체 지향 언어에서이 메커니즘은 상속 된 메소드입니다 : equals . OO 코드를 읽으면 모든 클래스에서 메소드가 정확히 동일한 구현을 기대하지는 않습니다. 우리는 상속과 오버로드에 익숙합니다.

그러나 연산자도 동일한 동작을 기대합니다. 'a == b'가 표시되면 모든 상황에서 동일한 유형의 동등 함 (위의 4부터)을 예상해야합니다. 따라서 일관성 을 유지하기 위해 언어 설계자는 모든 유형에 대해 참조 평등을 사용했습니다. 프로그래머가 메소드를 대체했는지 여부에 의존해서는 안됩니다.

추신 : 언어 Dee는 Java 및 C #과 약간 다릅니다. equals 연산자는 간단한 유형의 경우 얕은 평등을 의미하고 사용자 정의 클래스의 의미 적 평등을 의미합니다 (= 사용자와 거짓말하는 = 연산을 구현해야 함-기본값은 제공되지 않음). 단순 유형의 경우 얕은 평등은 항상 시맨틱 평등이므로 언어는 일관성이 있습니다. 그러나 지불하는 가격은 equals 연산자가 기본적으로 사용자 정의 유형에 대해 정의되어 있지 않다는 것입니다. 당신은 그것을 구현해야합니다. 때로는 지루합니다.

이 두 언어가 왜이 경로를 거꾸로 돌리고 == 논리적 평등을 유지하고 참조 평등을 위해 .ReferenceEquals ()를 사용하는 대신이 경로를 사용했는지 이유를 생각하려고했습니다.

후자의 접근 방식은 혼란 스러울 수 있기 때문입니다. 치다:

if (null.ReferenceEquals(null)) System.out.println("ok");

이 코드가 인쇄되어야합니까 "ok", 아니면 NullPointerException?

Java 및 C #의 경우 객체 지향적이라는 이점이 있습니다.

A로부터 보기의 성능 지점 - 쉽게 쓰기 코드도 빨리해야한다 : OOP는 객체가 매우 커질 수 있음을 고려하여, 참조 평등을 확인하는 것이 빠를 것, 다른 객체에 의해 표현 될 논리적으로 별개의 요소 의도 때문이다.

A로부터 뷰의 논리적 점 - (. 예를 널 (null) == null이 논리적으로 해석하는 방법이 경우에 경우 다를 수 있습니까?) 다른 개체의 평등 평등에 대한 개체의 속성에 비교으로 명백한으로 할 필요가 없습니다.

나는 그것이 "참조 평등보다 항상 논리적 평등을 원한다"는 당신의 관찰이라고 생각합니다. 언어 디자이너들 사이의 합의는 아마도 반대 일 것입니다. 광범위한 프로그래밍 경험이 없기 때문에 개인적으로 이것을 평가하기가 어렵다는 것을 알게되었습니다. 대략, 나는 최적화 알고리즘에서 참조 평등을 더 사용하고 데이터 세트를 처리하는 데 논리적 평등을 더 사용합니다.

.equals()변수를 내용으로 비교합니다. 그 대신 ==내용으로 객체를 비교합니다 ...

객체를 사용하는 것이 더 정확합니다 .equals()