이것은 인터페이스/API를 작성하는 컨텍스트에 있습니다.불변 및 일반 대 특정 유형
모범 사례는 인터페이스의 특정 유형보다는 일반적인 유형을 사용하는 것이 좋습니다. HashMap 대신 Map입니다.
모범 사례는 변경 가능 유형보다 변경 불가능 유형을 선호합니다.
그래서 이러한 제안을 모두 고려 (성능/메모리 풋 프린트, 제 3 자-라이브러리/의존성과 편의성/기능에 대한 우려를 제쳐두고) 점검이
public List<SomeClass> someMethod(...)
또는 오히려이 이는 구아바 사람들 사이에서 논의 된 경우
public ImmutableList<SomeClass> someMethod(...)
다음은 상기되었습니다
API로 교환되는 유형에 대한 기본 조언은 다음과 같습니다. 관련 의미 정보를 여전히 전달하는 가장 일반적인 유형을 선택하십시오.
ImmutableCollection에 의해 만들어진 의미 보증의 삼중 항은 거의 모든 상황에서 반환 값과 매우 관련이 있다고 생각합니다 (3 개는 불변, null 요소가없고 반복 순서가 보장됨). 그래서 사실상 Set를 반환하지 않고 ImmutableSet을 반환 할 것입니다.
우리는 사람들이 ImmutableSet 등을 모든 중요한 의미에서 인터페이스로 보는 것을 정말로 좋아할 것입니다. Java가 JDK 8까지 인터페이스에 정적 메소드를 허용하지 않을 것이라는 사실과 우리가 편의성을 위해 Java를 필요로하는 이유는 두 가지 밖에 없습니다.
대부분의 사람들은 ImmutableList가 이러한 이유로 구현 된 것이라고 생각하지만 실제로 이러한 유형 중 몇 가지가 수십 가지로 구현되어 있습니다. 당신은 단지 그들을 보지 못합니다.
메서드의 계약에 따라 List가 변경되지 않으면 반환 유형은 List가 아닌 ImmutableList 여야합니다. 이것은 List가 메소드의 JavaDoc에서 불변이라는 것을 단순히 언급하는 것보다 훨씬 명확합니다.
그러나 목록의 불변성이 계약이 아닌 구현 세부 사항이면 반환 유형은 목록이어야합니다.
API를 작성하는 것은 사용자와 계약을 맺는 것과 관련이 있습니다.
모범 사례는 주로 제 3 자용 API를 작성하고 인터페이스를 정의해야하는 컨텍스트에 대한 것입니다.
우리는 다른 상황에서 다른 시각을 가질 수 있습니다. 타사에서 사용할 라이브러리를 작성하는 경우 오브젝트 상태를 변경하거나 변경하지 말아야한다고 고려해야합니다.
API가 내부적으로 (동일한 코드베이스로) 사용되면 & 목적은 느슨한 결합을 달성하는 것이므로 쓰기 용이성, 확장 성 및 유지 보수성에 대해 고려해야합니다.
변경할 수없는 API는 개체 상태에 대해 많은 가정을했을 때 데이터 불일치를 특별히 방지합니다.반면에 변경 가능한 객체는 개발 노력을 절약 할 수 있습니다.
리턴 된 List가 변경 불가능한 것이 확실하다면, 2로보아야하고 그렇지 않으면 1로 보일 것입니다. 불변 목록 btw 무엇입니까? 내가 그것에 추가 할 수 없다면 그것은 정말로 목록인가? –
첫 번째 것 ... 그러나 불변 _collection_은 _elements_의 불변성을 의미하지 않는다. 단순히 컬렉션 자체를 변경할 수 없다는 것을 의미합니다 (요소 대체/제거/추가). – fge
@JohnRasch 오, 고마워. 나는 정말로 그 개념을 생각하거나 만난 적이 없다. –