Java가 운영자에게 과부하를 제공하지 않는 이유는?
C++에서 Java로 오면서, 분명한 해답이 없는 질문은 왜 Java가 운영자 과부하를 포함하지 않았는가 하는 것이다.
그렇지 않은가?Complex a, b, c; a = b + c;보다 훨씬 간단한Complex a, b, c; a = b.add(c);?
운영자 과부하를 허용하지 않는 것으로 알려진 유효한 주장이 있는가?그 이유는 임의적인 것인가, 아니면 시간에 구애받지 않는 것인가?
운영자가 과부하한 것에 대해 불평하는 게시물이 많다.
나는 이 개념에 대한 대안적인 관점을 제시하면서 "운영자 과부하" 개념을 분명히 해야 한다고 느꼈다.
코드 난독화?
이 주장은 오류다.
난독화는 모든 언어에서 가능하다...
C 또는 Java에서는 연산자 과부하를 통해 C++에서와 같이 기능/방법 등을 통해 코드를 난독화하기가 쉽다.
// C++
T operator + (const T & a, const T & b) // add ?
{
T c ;
c.value = a.value - b.value ; // subtract !!!
return c ;
}
// Java
static T add (T a, T b) // add ?
{
T c = new T() ;
c.value = a.value - b.value ; // subtract !!!
return c ;
}
/* C */
T add (T a, T b) /* add ? */
{
T c ;
c.value = a.value - b.value ; /* subtract !!! */
return c ;
}
...Java의 표준 인터페이스에서도
다른 예로 Java의 인터페이스를 보자.
이 인터페이스를 구현하는 개체를 복제해야 하는 경우.하지만 당신은 거짓말을 할 수 있다.그리고 다른 물체를 창조한다.사실, 이 인터페이스는 너무 약해서 재미로 다른 종류의 물체를 완전히 반환할 수 있다.
class MySincereHandShake implements Cloneable
{
public Object clone()
{
return new MyVengefulKickInYourHead() ;
}
}
처럼Cloneable인터페이스가 남용/난독화될 수 있으며, C++ 연산자 과부하가 발생해야 하는 동일한 이유로 인터페이스가 금지되어야 하는가?
과부하가 걸릴 수도 있어toString()의 MyComplexNumber하루의 끈으로 묶은 시간을 되돌려 주기 위해 수업한다.~해야 하는가toString()과부하도 금지된다고?우리가 방해할 수도 있어MyComplexNumber.equals임의의 값을 반환하도록 하고 피연산자를 수정한다...등
자바에서, C++ 또는 어떤 언어에서처럼, 프로그래머는 코드를 쓸 때 최소한 의미론을 존중해야 한다.이는 다음을 구현하는 것을 의미한다.add 추가는 기다.Cloneable 방법,하는 방법은 구현및이다.++증분보다 연산자.
근데 뭐가 난독해?
자연 그대로의 자바 방식을 통해서도 코드가 파괴될 수 있다는 것을 알게 된 지금, 우리는 C++에서 연산자 과부하의 실제 사용에 대해 자문해 볼 수 있다.
명확하고 자연스러운 표기법: 방법 대 연산자 과부하?
아래에서는 Java와 C++의 "동일한" 코드를 비교하여 어떤 종류의 코딩 스타일이 더 명확한지 알아보도록 하겠다.
자연 비교:
// C++ comparison for built-ins and user-defined types
bool isEqual = A == B ;
bool isNotEqual = A != B ;
bool isLesser = A < B ;
bool isLesserOrEqual = A <= B ;
// Java comparison for user-defined types
boolean isEqual = A.equals(B) ;
boolean isNotEqual = ! A.equals(B) ;
boolean isLesser = A.comparesTo(B) < 0 ;
boolean isLesserOrEqual = A.comparesTo(B) <= 0 ;
작업자의 과부하가 제공되는 한 A와 B는 C++의 어떤 유형일 수 있다는 점에 유의하십시오.자바에서는 A와 B가 원시성이 아닐 때 원시적인 물체(BigInteger 등)에서도 코드가 매우 혼동될 수 있다...
자연 어레이/컨테이너 액세스자 및 첨자:
// C++ container accessors, more natural
value = myArray[25] ; // subscript operator
value = myVector[25] ; // subscript operator
value = myString[25] ; // subscript operator
value = myMap["25"] ; // subscript operator
myArray[25] = value ; // subscript operator
myVector[25] = value ; // subscript operator
myString[25] = value ; // subscript operator
myMap["25"] = value ; // subscript operator
// Java container accessors, each one has its special notation
value = myArray[25] ; // subscript operator
value = myVector.get(25) ; // method get
value = myString.charAt(25) ; // method charAt
value = myMap.get("25") ; // method get
myArray[25] = value ; // subscript operator
myVector.set(25, value) ; // method set
myMap.put("25", value) ; // method put
자바에서는 각 컨테이너가 동일한 작업을 하기 위해(인덱스나 식별자를 통해 콘텐트에 액세스하기 위해), 우리는 다른 방법을 가지고 있어 혼란스럽다고 본다.
C++에서, 각 컨테이너는 작업자의 과부하로 인해 컨텐츠에 액세스하기 위해 동일한 방법을 사용한다.
자연발달형식조작
아래의 예는 a를 사용한다.Matrix"Java Matrix 개체" 및 "C++ Matrix 개체"에 대해 구글에서 발견된 첫 번째 링크를 사용하여 발견된 개체:
// C++ YMatrix matrix implementation on CodeProject
// http://www.codeproject.com/KB/architecture/ymatrix.aspx
// A, B, C, D, E, F are Matrix objects;
E = A * (B / 2) ;
E += (A - B) * (C + D) ;
F = E ; // deep copy of the matrix
// Java JAMA matrix implementation (seriously...)
// http://math.nist.gov/javanumerics/jama/doc/
// A, B, C, D, E, F are Matrix objects;
E = A.times(B.times(0.5)) ;
E.plusEquals(A.minus(B).times(C.plus(D))) ;
F = E.copy() ; // deep copy of the matrix
그리고 이것은 행렬에 국한되지 않는다.그BigInteger그리고BigDecimalJava의 클래스는 동일한 혼란스러운 장점으로 고통 받고 있는 반면, C++의 등가물은 내장형처럼 명확하다.
자연 반복기:
// C++ Random Access iterators
++it ; // move to the next item
--it ; // move to the previous item
it += 5 ; // move to the next 5th item (random access)
value = *it ; // gets the value of the current item
*it = 3.1415 ; // sets the value 3.1415 to the current item
(*it).foo() ; // call method foo() of the current item
// Java ListIterator<E> "bi-directional" iterators
value = it.next() ; // move to the next item & return the value
value = it.previous() ; // move to the previous item & return the value
it.set(3.1415) ; // sets the value 3.1415 to the current item
천연 펑커:
// C++ Functors
myFunctorObject("Hello World", 42) ;
// Java Functors ???
myFunctorObject.execute("Hello World", 42) ;
텍스트 연결:
// C++ stream handling (with the << operator)
stringStream << "Hello " << 25 << " World" ;
fileStream << "Hello " << 25 << " World" ;
outputStream << "Hello " << 25 << " World" ;
networkStream << "Hello " << 25 << " World" ;
anythingThatOverloadsShiftOperator << "Hello " << 25 << " World" ;
// Java concatenation
myStringBuffer.append("Hello ").append(25).append(" World") ;
좋아, 자바에서는 사용할 수 있다.MyString = "Hello " + 25 + " World" ; 하지만, 잠깐만.이건 작업자가 과부하한 거잖아, 안 그래?바람피우는 거?
:-D
일반 코드?
기본 제공/기본 요소(Java에 인터페이스가 없는 경우), 표준 개체(올바른 인터페이스를 가질 수 없는 경우) 및 사용자 정의 개체 모두에 동일한 일반 코드 수정 피연산자를 사용할 수 있어야 한다.
예를 들어, 임의 유형의 두 값의 평균 값 계산:
// C++ primitive/advanced types
template<typename T>
T getAverage(const T & p_lhs, const T & p_rhs)
{
return (p_lhs + p_rhs) / 2 ;
}
int intValue = getAverage(25, 42) ;
double doubleValue = getAverage(25.25, 42.42) ;
complex complexValue = getAverage(cA, cB) ; // cA, cB are complex
Matrix matrixValue = getAverage(mA, mB) ; // mA, mB are Matrix
// Java primitive/advanced types
// It won't really work in Java, even with generics. Sorry.
연산자 과부하 논의 중
이제 연산자 과부하를 이용한 C++ 코드와 자바에서 동일한 코드와의 공정한 비교를 보았으니, 이제 개념으로서 「운영자 과부하」를 논할 수 있다.
컴퓨터 이전부터 연산자 오버로드 작업이 존재
컴퓨터 과학의 외부에서도 연산자의 과부하가 있다.예를 들어, 수학에서 연산자는+-*, 등이 과부하하다.
'로'의.+-* )에
우리들 대부분은, 우리의 과학 강좌의 일부로서, 오퍼레이터의 종류에 따라, 오퍼레이터에게 복수의 의의를 배웠다.그럼 우리가 헷갈리는걸 발견했나?
운영자 오버로드 여부는 해당 운영자에 따라 다름
이것은 연산자의 과부하에서 가장 중요한 부분이다: 수학이나 물리학에서처럼 연산은 연산자의 유형에 따라 달라진다.
피연산자의 유형을 알면 수술의 효과를 알 수 있을 것이다.
C와 Java에도 연산자 과부하(하드 코딩)가 있음
C에서 운용자의 실제 동작은 운용자에 따라 변한다.예를 들어, 두 개의 정수를 추가하는 것은 두 개의 복수를 추가하는 것과, 심지어 한 개의 정수와 한 개의 복수를 추가하는 것과는 다르다.전체 포인터 산술 영역도 있다(캐스팅 없이 포인터에는 정수를 추가할 수 있지만 포인터 2개를 추가할 수는 없다...).
자바에서는 포인터 산술은 없지만, 어떤 사람은 아직 포인터 산술 없이 끈 결합을 발견했다.+운영자는 "과잉 과부하가 악하다"는 신조에서 예외를 정당화하기에 충분히 우스꽝스러울 것이다.
단지 C(역사적 이유로)나 자바(개인적 이유로 아래 참조) 코더로서 당신 자신의 것을 제공할 수 없다는 것이다.
C++에서 연산자 과부하가 선택 사항이 아님...
C++에서는 내장형(built-in type)에 대한 연산자 과부하가 불가능하지만(그리고 이것은 좋은 일이다), 사용자 정의형은 사용자 정의 연산자 과부하가 발생할 수 있다.
이미 앞에서 말한 바와 같이 C++에서는, 그리고 자바와는 반대로, 사용자 타입은 빌트인 타입과 비교했을 때, 언어의 2등 시민으로 간주되지 않는다.따라서, 내장형 타입에 연산자가 있다면, 사용자 타입도 연산자를 가질 수 있어야 한다.
, 마마처럼...toString()clone()equals()방법은 자바(즉, 준표준 유사), C++ 연산자의 과부하가 C++의 많은 부분을 차지하기 때문에 원래의 C 연산자처럼 자연스러워지거나, 앞에서 언급한 자바 방법처럼 자연스러워진다.
템플릿 프로그래밍과 결합되어 연산자 오버로드는 잘 알려진 설계 패턴이 된다.사실 STL에서는 과부하 연산자, 과부하 연산자를 사용하지 않고서는 아주 멀리 갈 수 없다.
...하지만 악용되어서는 안 된다.
작업자 과부하 시 작업자의 의미론을 존중하도록 노력해야 한다.A에서 빼지 않음+연산자("에서 뺄셈을 하지 말라"와 같이)add함수) 쓰레기(return in a function(기))"는 "반환 보루"이다.clonemethod").
주물 과부하로 인해 애매모호해질 수 있기 때문에 매우 위험할 수 있다.그래서 그들은 잘 정의된 사례에 대해 정말로 유보적이어야 한다.에 관하여&&그리고||, 당신이 정말로 당신이 무엇을 하고 있는지 알고 있지 않는 한 결코 과부하하지 마십시오, 당신은 당신이 원주민 운영자들이 하는 단락 평가를 잃게 될 것이기 때문이다.&&그리고||즐거운 시간 되세요.
그래서... 알았어...그렇다면 왜 자바에서는 불가능한가?
왜냐하면 제임스 고슬링이 그렇게 말했기 때문이다.
나는 C++에서 너무 많은 사람들이 그것을 남용하는 것을 보았기 때문에 교환원의 과부하를 상당히 개인적인 선택으로 배제했다.
제임스 고슬링.출처: http://www.gotw.ca/publications/c_family_interview.htm
위의 고슬링의 텍스트와 아래의 스트루스트럽의 텍스트를 비교하십시오.
많은 C++ 디자인 결정들은 내가 어떤 특정한 방법으로 사람들에게 일을 하도록 강요하는 것을 싫어하는 데 뿌리를 두고 있다 [...] 나는 종종 내가 개인적으로 싫어하는 특징을 불법으로 금지하고 싶은 유혹을 받았다, 나는 다른 사람들에게 나의 견해를 강요할 권리가 있다고 생각하지 않았기 때문에 나는 그렇게 하는 것을 자제했다.
비야른 스트루스트럽출처:C++(1.3 일반배경)의 설계와 진화
작업자의 과부하로 Java에 이득이 되는가?
일부 개체는 연산자 과부하(BigDecimal, 복잡한 숫자, 행렬, 용기, 반복기, 대조기, 파서 등 구체적 또는 숫자 유형)의 혜택을 크게 받을 수 있다.
C++에서는 스트루스트럽의 겸손함 때문에 이 혜택을 얻을 수 있다.자바에선 고슬링의 개인적인 선택 때문에 망한 거야
자바에 추가될 수 있을까?
지금 자바에서 연산자 과부하를 추가하지 않는 이유는 내부정치, 기능에 대한 알레르기, 개발자에 대한 불신(자바 팀을 괴롭히는 것 같은 파괴자)과의 호환성, 이전 JVM과의 호환성, 정확한 사양서 작성 시간 등이 복합적으로 작용했을 수 있다.
그러니 이 기능을 기다리며 숨을 죽이지 마라...
하지만 그들은 그것을 C#!!!
네...
이것이 두 언어의 유일한 차이점과는 거리가 멀지만, 이 언어는 결코 나를 즐겁게 하지 않는다.
분명히, C# 사람들은 "모든 원시인들은 a이고, 개체로부터 파생된 것"을 가지고, 첫 시도에서 그것을 맞혔다.
그리고 그들은 그것을 다른 언어로 한다!!!
Despite all the FUD against used defined operator overloading, the following languages support it: Kotlin, Scala, Dart, Python, F#, C#, D, Algol 68, Smalltalk, Groovy, Perl 6, C++, Ruby, Haskell, MATLAB, Eiffel, Lua, Clojure, Fortran 90, Swift, Ada, Delphi 2005...
너무나 많은 언어들, 너무나 많은 다른 (그리고 때로는 반대되는) 철학들을 가지고 있지만, 그럼에도 불구하고 그들은 모두 그 점에 동의한다.
생각할 수 있는 음식...
제임스 고슬링은 자바 디자인을 다음과 같이 비유했다.
"한 아파트에서 다른 아파트로 이사할 때 이사하는 데는 이런 원칙이 있지.재미있는 실험은 아파트를 싸서 모든 것을 상자에 넣은 다음, 다음 아파트로 옮겨서 필요할 때까지 아무것도 풀지 않는 것이다.그러니까 첫 식사를 만들고, 상자에서 무언가를 꺼내는 거군.그리고 한 달 정도 지난 후에 여러분은 인생에서 실제로 필요한 것이 무엇인지 알아내고, 나머지 것들을 -- 얼마나 좋아하는지, 얼마나 멋진지는 잊어버리고 -- 그냥 버리는 겁니다.그렇게 해서 생활을 단순화하는 것은 놀라운 일이며, 그 원리를 모든 종류의 디자인 문제에서 사용할 수 있다. 즉, 멋있다고 해서 또는 흥미롭다고 해서 일을 하지 않는다는 것이다.
여기서 인용문의 맥락을 읽을 수 있다.
기본적으로 운영자 과부하는 어떤 종류의 포인트, 통화 또는 복잡한 숫자를 모델링하는 클래스에 적합하다.하지만 그 후에 당신은 빠르게 예시가 바닥나기 시작한다.
또 다른 요인은 개발자들이 '&', '||', 출연자 그리고 물론 'new'와 같은 사업자들에게 과부하를 가함으로써 C++의 기능을 남용한 것이다.이를 가치와 예외에 따른 복잡성은 Exception C++ 책에서 잘 다루어진다.
Boost를 확인하십시오.단위: 링크 텍스트
오버헤드 제로 치수 분석을 연산자 과부하를 통해 제공한다.이게 얼마나 더 선명해질 수 있을까?
quantity<force> F = 2.0*newton;
quantity<length> dx = 2.0*meter;
quantity<energy> E = F * dx;
std::cout << "Energy = " << E << endl;
"에너지 = 4 J"를 출력할 수 있으며, 이는 정확하다.
자바 설계자들은 운영자의 과부하가 가치 있는 것보다 더 큰 문제라고 결정했다.그렇게 간단하다.
모든 객체 변수가 실제로 참조인 언어에서, 연산자 과부하는 최소한 C++ 프로그래머에게 상당히 비논리적일 수 있는 추가적인 위험을 얻는다.C#의== 및 C#의 == 자자 과하하와 한다.Object.Equals그리고Object.ReferenceEquals(혹은 뭐라고 부르든 간에)
韓國의 韓國의 韓國의 日本經濟의 日本經濟의 日本經濟의 日本經濟의 의 日本經濟의 日本經濟의 日本經濟의 日本經濟의 日本經濟의 日本語를 a, 그러면 멤버 함수가 호출되어야 할 것이다.
Complex a, b, c;
// ...
a = b.add(c);
C++에서 이 표현식은 컴파일러에게 스택에 3개의 객체를 만들고, 추가를 수행하고, 결과 값을 임시 객체의 기존 객체로 복사하도록 지시한다.a.
그러나 자바에서는operator=참조 유형에 대한 값 복사를 수행하지 않으며, 사용자는 값 유형이 아닌 새로운 참조 유형만 생성할 수 있다.따라서 이름이 지정된 사용자 정의 유형의 경우Complex, 할당이란 기존 값에 참조를 복사하는 것을 의미한다.
대신 다음을 고려하십시오.
b.set(1, 0); // initialize to real number '1'
a = b;
b.set(2, 0);
assert( !a.equals(b) ); // this assertion will fail
C++에서는 값을 복사하므로 비교 결과는 같지 않다.자바에서는operator= 참조 복 사 사 수 수 수 수 수 수::a그리고b현재 동일한 가치를 언급하고 있다.그 결과, 그 물체는 그 자신과 동등하게 비교되기 때문에, 그 비교는 '같음'을 산출하게 될 것이다.
사본과 참고문헌의 차이는 운영자의 과부하 혼란만 가중시킬 뿐이다. @세바스티안 이, 자자자자자자 C# 가가 가기 기는 도(道)로 다어어어다.operator+것 가곡은 다사다리를 한다.operator=참고자료를 다루기 위해 이미 시행되었다.
C++에서는 한 번에 한 종류의 비교만 다루어야 하므로 혼동을 줄일 수 있다.예를 들어,Complexoperator=그리고operator==각각 값을 복사하고 값을 비교하는 작업.
그루비는 운영자 과부하로 JVM에서 작동한다.공연히 히트하는 것을 개의치 않는다면(매일 작아진다).메서드 이름을 기준으로 자동이다.예: '+'는 'plus(인론)' 메서드를 부른다.
나는 이것이 개발자들에게 그들의 의도를 명확하게 전달하는 기능을 만들도록 강요하기 위한 의식적인 설계 선택이었을지도 모른다고 생각한다.C++ 개발자는 주어진 운영자의 공통적으로 수용되는 성격과 관계없는 기능성으로 운영자에게 과부하될 수 있으므로, 운영자의 정의를 보지 않고는 코드 조각이 무엇을 하는지를 결정하는 것이 거의 불가능하다.
조작자의 과부하로 발에 총을 쐈을 수도 있지그것은 마치 사람들이 그들에게 바보 같은 실수를 저지르는 것과 같아서 가위를 빼앗기로 결정했다.
적어도 나는 그것이 이유라고 생각한다.어쨌든 난 네 편이야.:)
일부 사람들은 운영자가 자바에서 과부하하면 모호하게 될 것이라고 말한다.그 사람들이 BigDecimal을 사용하여 재정적인 가치를 백분율로 증가시키는 것과 같은 기본적인 계산을 하는 몇몇 자바 코드를 보기 위해 멈춰본 적이 있는가? .... 그러한 연습의 장황함은 그 자체로 모호함을 증명하는 것이 된다.아이러니하게도, 자바에 연산자를 과부하하는 것을 추가하면, 우리는 그러한 수학적인 코드를 우아하고 단순하게 만들 수 있는 우리만의 통화 클래스를 만들 수 있을 것이다.
기술적으로, 정수나 실수와 같은 다른 유형의 숫자를 다룰 수 있는 모든 프로그래밍 언어에는 연산자가 과부하되어 있다.설명:과부하라는 용어는 하나의 기능에 대해 단순히 여러 개의 구현이 있다는 것을 의미한다.대부분의 프로그래밍 언어에서 다른 구현이 연산자 +, 정수를 위한 하나, 리얼을 위한 하나, 이것을 연산자 과부하라고 한다.
자바에 연산자 과부하가 있다는 것은 이상하다는 사람들이 많은데, 수학적인 관점에서 보면 이것은 정말 이상하겠지만, 프로그래밍 언어의 개발자 입장에서 보면 연산자 과부하를 연산자 과부하(builtin operator + for operator for the operator for the operator for another classes)를 추가하는 것은 문제될 것이 없다.끈그러나 대부분의 사람들은 +에 대한 기본 과부하를 추가하면 일반적으로 개발자에게도 이러한 기능을 제공하는 것이 좋다는 데 동의한다.
A는 코드 과부하로 인한 난독화라는 오류에 전적으로 동의하지 않는데, 이는 개발자가 결정해야 할 사항이기 때문이다.이것은 생각하는 것은 순진하고, 솔직히 말해서, 늙어가고 있다.
Java 8에서 연산자 과부하를 추가하기 위한 +1.
연산자의 과부하가 연산자의 논리 로직과 일치하지 않는 유형의 논리적 오류를 초래한다고 말하는 것은, 아무 말도 하지 않는 것과 같다.기능 이름이 작동 논리에 적합하지 않은 경우에도 같은 유형의 오류가 발생할 것이다. 그렇다면 해결책은 무엇인가? 기능 사용 능력을 떨어뜨리는 것이다!?이것은 코믹한 대답이다 - "작동논리에 적합하지 않다" - 모든 매개변수 이름, 모든 클래스, 기능 또는 논리적으로 부적절할 수 있는 모든 것.나는 이 옵션이 존경할 만한 프로그램 언어로 이용 가능해야 한다고 생각한다. 그리고 그것이 안전하지 않다고 생각하는 사람들은 둘 다 당신이 그것을 사용해야 한다고 말하지 않는다.C#를 가져갑시다.그들은 포인터를 축 늘어뜨렸지만, 이봐 - '안전하지 않은 코드'라는 문장이 있어 - 당신이 원하는 대로 프로그램 할 수 있다.
때로는 운영자 과부하, 친구 수업, 다중 상속이 있으면 좋을 것이다.
하지만 나는 여전히 그것이 좋은 결정이었다고 생각한다.만약 자바에 연산자 과부하가 있었다면 우리는 소스 코드를 살펴보지 않고는 연산자 의미를 결코 확신할 수 없었을 것이다.지금은 그럴 필요가 없다.그리고 나는 연산자 과부하 대신에 방법을 사용하는 너의 예 또한 꽤 읽을 수 있다고 생각한다.만약 당신이 상황을 좀 더 명확하게 하고 싶다면 당신은 언제나 과장된 진술 위에 코멘트를 추가할 수 있다.
// a = b + c
Complex a, b, c; a = b.add(c);
Java를 구현 언어로 가정하면, 초기 값이 null인 complex에 대한 참조가 될 것이다.또한 콤플렉스가 언급된 BigInteger와 유사 불변 BigDecimal과 같이 불변하다고 가정할 때, b와 c를 추가하여 반환된 콤플렉스에 참조를 할당하고 이 참조를 a와 비교하지 않고, 다음과 같은 것을 의미하는 것 같다.
그렇지 않은 경우:
Complex a, b, c; a = b + c;다음보다 훨씬 간단하다.
Complex a, b, c; a = b.add(c);
Java 운영자 과부하 기본 지원의 대안
Java에는 연산자 과부하가 없으므로 다음 사항을 살펴볼 수 있는 몇 가지 대안이 있다.
- 다른 언어를 사용한다.그루비와 스칼라 모두 연산자 과부하가 있으며, 자바에 기반을 두고 있다.
- Java에서 연산자 오버로드를 지원하는 플러그인인 Java-oo를 사용하십시오.플랫폼에 독립적이지 않다는 점에 유의하십시오.또한 많은 문제를 안고 있으며, 최신 Java 릴리즈(즉, Java 10). (Original StackOverflow Source)와 호환되지 않는다.
- JNI, Java Native Interface 또는 대안을 사용하십시오.이것은 당신이 자바에서 사용하기 위해 C 또는 C++ (아마도 다른 방법들?) 메소드를 쓸 수 있게 해준다.물론 이것은 플랫폼에 독립적이지도 않다.
다른 사람을 알고 있는 사람이 있으면 코멘트를 해 주면 이 리스트에 추가하겠다.
나는 결정을 내리는 사람들이 단지 복잡한 가치, 행렬 대수학, 집합 이론, 그리고 과부하가 언어에 모든 것을 쌓지 않고 표준 표기법을 사용할 수 있는 다른 경우를 잊어버렸다고 생각한다.어쨌든, 오직 수학적으로 지향적인 소프트웨어만이 그러한 특징으로부터 정말로 이익을 얻는다.일반적인 고객 애플리케이션은 거의 필요하지 않다.
그들은 불필요한 난독화에 대한 논쟁은 프로그래머가 그 기능이 대신 될 수 있는 프로그램 특정 운영자를 정의할 때 분명히 유효하다.함수의 이름이 선명하게 보이면 함수의 이름이 함수를 암시한다.연산자는 판독 가능한 이름이 없는 함수다.
자바는 일반적으로 어떤 추가적인 장황함이 코드를 더 읽기 쉽게 만들기 때문에 나쁘지 않다는 철학에 대해 설계된다.같은 일을 하는 구조물은 과거에 "합세 설탕"이라고 불렸던 적이 있다.이것은 예를 들어, 짧은 것이 항상 더 나은 것으로 보이는 파이톤 철학과는 매우 다르다. 비록 두 번째 독자들에게는 더 적은 맥락을 제공한다고 해도 말이다.
이것은 그것을 허용하지 않는 좋은 이유가 아니라 실용적인 이유인 것이다.
사람들은 항상 그것을 책임감 있게 사용하지 않는다.Python 라이브러리 스크래피에서 다음 예를 참조하십시오.
>>> IP()
<IP |>
>>> IP()/TCP()
<IP frag=0 proto=TCP |<TCP |>>
>>> Ether()/IP()/TCP()
<Ether type=0x800 |<IP frag=0 proto=TCP |<TCP |>>>
>>> IP()/TCP()/"GET / HTTP/1.0\r\n\r\n"
<IP frag=0 proto=TCP |<TCP |<Raw load='GET / HTTP/1.0\r\n\r\n' |>>>
>>> Ether()/IP()/IP()/UDP()
<Ether type=0x800 |<IP frag=0 proto=IP |<IP frag=0 proto=UDP |<UDP |>>>>
>>> IP(proto=55)/TCP()
<IP frag=0 proto=55 |<TCP |>>
설명은 다음과 같다.
/ 연산자는 두 레이어 사이의 합성 연산자로 사용되어 왔다.그럴 때, 하위 계층은 상위 계층에 따라 하나 이상의 기본 필드가 과부하될 수 있다. (아직도 원하는 값을 제공할 수 있다.)끈은 원단으로 사용할 수 있다.
Java 언어가 연산자 과부하를 직접 지원하지는 않지만, Java 프로젝트에서 다지관 컴파일러 플러그인을 사용하여 실행할 수 있다.자바 8 - 17(현 자바 버전)을 지원하고, 인텔리제이 IDEA에서 전폭적으로 지원한다.
참조URL: https://stackoverflow.com/questions/77718/why-doesnt-java-offer-operator-overloading
'Programing' 카테고리의 다른 글
| mapState의 Vue 계산 구문 오류 (0) | 2022.04.14 |
|---|---|
| Vuetifyjs 2.0 테마는 관찰자에 따라 변경되지 않음 (0) | 2022.04.13 |
| 오류: mksdcard SDK 도구를 실행할 수 없음 (0) | 2022.04.13 |
| Vuex: 소방기지 라우팅.if 문 (0) | 2022.04.13 |
| vue 2 구성 요소가 포함된 vue 라우터가 5.8과 함께 작동하지 않음 (0) | 2022.04.13 |