메소드 매개 변수 유형, 리턴 유형 및 특성 유형의 구체성에 대한 규칙

얼마 전에 메소드 매개 변수 유형, 리턴 유형 및 특성 유형의 구체성에 대한 일종의 경험 법칙을 읽었지만 기억하지는 않습니다.

반환 유형을 최대한 구체적으로 유지하고 매개 변수 유형을 최대한 추상적으로 유지하거나 그 반대로 유지하는 것에 대해 설명했습니다.

그것이 실제로 좋은 조언인지 나쁜 조언인지 모르겠습니다. 그러면 자신의 생각이 있다면 의견을 말하십시오.

건배.

더 이상 필요없고 약속하십시오.

이 문구는 Bertrand Meyer가 개척 한 "Design by Contract"아이디어에서 나옵니다.

http://wiki3.cosc.canterbury.ac.nz/index.php/Design_by_contract

"Liskov 대체 원리"참조

/programming/56860/what-is-the-liskov-substitution-principle

추상적 인 입력과 구체적인 출력이 있으면 기능이 더 일반적입니다. 이것은 더 많은 방법으로 사용될 수 있음을 의미합니다. 반면에 메소드의 강력한 제약 조건을 적용하여 향후 메소드 구현 방식을 제한합니다. 서로 다른 목표 사이의 절충점입니다.

Postel의 법칙 의 외삽을들을 수 있습니다 . "보내는 것에 보수적이며, 받아들이는 것에 자유주의하십시오."

주로 코드 재사용 성을 최대화하는 것입니다. 도움이되는 이유를 보여주는 사례를 쉽게 제시 할 수 있습니다. 자바를 Iterable<T>예로 들어 보자. 메소드가 모든 것을 반복 T하는 경우 Iterable<T>매개 변수 유형으로 as를 사용하면 인터페이스를 구현하는 사용자 정의 클래스는 말할 것도없고 60 개 이상의 내장 클래스에서 해당 메소드를 사용할 수 있습니다. 예를 들어으로 제한하면 Vector<T>메서드를 호출하는 모든 코드를 Vector<T>첫 번째 코드로 변환해야합니다 .

반면에 from 메소드를 리턴 하면 Iterable<T>리턴 값을 사용할 수있는 코드의 양이 Iterable<T>매개 변수 를 사용하는 코드로 제한 됩니다. 당신은 매우 구체적인 형식을 반환하는 경우처럼 Vector<T>, 당신의 반환 값은 걸리는 어떤 방법으로 전달 될 수있다 Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, 또는 AbstractCollection<T>예상대로, 그것은 작동합니다.