'IList'vs 'ICollection'vs 'Collection'반환
공개 API 메서드 및 속성에서 반환 해야하는 컬렉션 유형에 대해 혼란스러워합니다.
내가 생각하고있는 모음입니다 IList, ICollection하고 Collection.
이러한 유형 중 하나를 반환하는 것이 항상 다른 유형보다 선호됩니까, 아니면 특정 상황에 따라 달라 집니까?
일반적으로 가능한 일반적인 유형, 즉 소비자가 사용해야하는 리턴 된 데이터를 충분히 알고있는 유형을 리턴해야합니다. 그렇게하면 API를 사용하는 코드를 중단하지 않고도 API 구현을 자유롭게 변경할 수 있습니다.
IEnumerable<T>인터페이스를 리턴 유형으로 고려하십시오 . 결과가 반복되는 경우 소비자는 그 이상을 필요로하지 않습니다.
ICollection<T>같은 수집 의미를 노출시키는 인터페이스는 Add(), Remove(), 및 Count.
Collection<T>ICollection<T>인터페이스 의 구체적인 구현입니다 .
IList<T>본질적 ICollection<T>으로 무작위 순서 기반 액세스입니다.
이 경우 결과에 순서 기반 인덱싱 (사용 IList<T>) 과 같은 목록 의미가 필요한지 또는 정렬되지 않은 결과의 "가방"을 반환해야하는지 (그런 다음 )를 결정해야합니다 ICollection<T>.
주요 차이점 IList<T>및 ICollection<T>즉 IList<T>인덱스를 통해 액세스 요소로 할 수 있습니다. IList<T>배열과 같은 유형을 설명합니다. 의 요소는 ICollection<T>열거를 통해서만 액세스 할 수 있습니다. 둘 다 요소를 삽입하고 삭제할 수 있습니다.
컬렉션을 열거하기 만하면 IEnumerable<T>선호됩니다. 다른 것보다 두 가지 장점이 있습니다.
컬렉션에 대한 변경을 허용하지 않지만 참조 유형 인 경우 참조 된 객체는 변경할 수 없습니다.
알고리즘 적으로 생성되고 컬렉션이 아닌 열거를 포함하여 가능한 가장 다양한 소스를 허용합니다.
Collection<T>컬렉션의 구현 자에게 주로 유용한 기본 클래스입니다. 인터페이스 (API)에 노출하면 그로부터 파생되지 않은 많은 유용한 컬렉션이 제외됩니다.
한 가지 단점은 IList<T>배열이이를 구현하지만 항목을 추가하거나 제거 할 수 없다는 것입니다 (즉, 배열 길이를 변경할 수 없음). IList<T>.Add(item)배열 을 호출하면 예외가 발생합니다 . 시도하기 전에 확인할 수 IList<T>있는 부울 특성이 있으므로 상황이 다소 혼란스러워집니다 IsReadOnly. 그러나 내 눈에 이것은 여전히 라이브러리의 디자인 결함입니다 . 따라서 List<T>항목을 추가하거나 제거 할 수 있어야 할 때 직접 사용 합니다.
IList<T>모든 일반 목록의 기본 인터페이스입니다. 순서가 지정된 컬렉션이므로 구현에서 정렬 순서에서 삽입 순서에 이르기까지 순서를 결정할 수 있습니다. 또한 Ilist메소드가 색인을 기반으로 목록의 항목을 읽고 편집 할 수 있도록하는 Item 속성이 있습니다. 이를 통해 위치 인덱스의 목록에 값을 삽입하거나 제거 할 수 있습니다.
또한 이후 IList<T> : ICollection<T>모든 ICollection<T>구현 방법 을 구현할 수 있습니다.
ICollection<T>모든 일반 컬렉션의 기본 인터페이스입니다. 크기, 열거 자 및 동기화 방법을 정의합니다. 컬렉션에 항목을 추가하거나 제거 할 수 있지만 인덱스 속성이 없어서 어떤 위치에서 발생하는지 선택할 수 없습니다.
Collection<T>에 대한 구현을 제공 IList<T>, IList하고 IReadOnlyList<T>.
ICollection<T>대신에 보다 좁은 인터페이스 유형을 사용하면 IList<T>변경 내용이 변경되지 않도록 코드를 보호 할 수 있습니다. 와 같은 더 넓은 인터페이스 유형을 사용하면 IList<T>코드 변경이 중단 될 위험이 더 큽니다.
출처 에서 인용 ,
ICollection,ICollection<T>: 컬렉션을 수정하거나 크기를 신경 씁니다.IList,IList<T>: 컬렉션을 수정하고 컬렉션에서 요소의 순서 및 / 또는 위치를 관리하려고합니다.
인터페이스 유형을 반환하는 것이 더 일반적이므로 특정 사용 사례에 대한 추가 정보가 부족합니다. 인덱싱 지원을 표시하려면을 선택하십시오 IList<T>. 그렇지 않으면 ICollection<T>충분합니다. 마지막으로, 리턴 된 유형이 읽기 전용임을 나타내려면을 선택하십시오 IEnumerable<T>.
그리고 이전에 읽지 않은 경우 Brad Abrams와 Krzysztof Cwalina는 "프레임 워크 디자인 지침 : 규칙, 숙어 및 재사용 가능한 .NET 라이브러리의 패턴"( 여기 에서 다이제스트를 다운로드 할 수 있음)이라는 제목의 훌륭한 책을 썼습니다 .
이 질문에서 나온 몇 가지 주제가 있습니다.
- 인터페이스와 클래스
- 여러 유사 클래스, 컬렉션, 목록, 배열 중 어떤 특정 클래스?
- 공통 클래스 대 하위 항목 ( "일반") 콜렉션
객체 지향 API 임을 강조하고 싶을 수도 있습니다.
인터페이스와 클래스
인터페이스에 대한 경험이 많지 않으면 수업을 따르는 것이 좋습니다. 인터페이스가 필요하지 않더라도 많은 개발자들이 인터페이스로 뛰어 드는 것을 봅니다.
그리고 좋은 클래스 디자인 대신 나쁜 인터페이스 디자인을 끝내십시오. 결국 좋은 디자인으로 마이그레이션 할 수 있습니다 ...
API에는 많은 인터페이스가 표시되지만 필요하지 않은 경우 서두르지 마십시오.
결국 코드에 인터페이스를 적용하는 방법을 배우게됩니다.
여러 유사 클래스, 컬렉션, 목록, 배열 중 어떤 특정 클래스?
C # (dotnet)에는 상호 교환 할 수있는 여러 클래스가 있습니다. 이미 언급했듯이 "CanBeSortedClass"와 같이보다 구체적인 클래스의 무언가가 필요한 경우 API에서 명시 적으로 만드십시오.
API 사용자는 클래스를 정렬하거나 요소에 어떤 형식을 적용 할 수 있는지 실제로 알아야합니까? 그런 다음 "CanBeSortedClass"또는 "ElementsCanBePaintedClass"를 사용하고, 그렇지 않으면 "GenericBrandClass"를 사용하십시오.
그렇지 않으면 더 일반적인 클래스를 사용하십시오.
공통 콜렉션 클래스와 하위 항목 ( "일반") 콜렉션
다른 요소를 포함하는 클래스가 있으며 모든 요소가 특정 유형이어야 함을 지정할 수 있습니다.
일반 컬렉션은 이 같은 새로운 각 하위 항목 유형, 새 컬렉션을 만들 필요없이, 몇 가지 코드 응용 프로그램의 경우 같은 모음을 사용하는 클래스입니다 : 컬렉션 .
API 사용자는 모든 요소에 대해 매우 특정한 유형이 필요합니까?
같은 것을 사용하십시오 List<WashingtonApple>.
API 사용자는 몇 가지 관련 유형이 필요합니까?
노출 List<Fruit>당신의 API를 들어, 및 사용 List<Orange> List<Banana>, List<Strawberry>내부, 어디서 Orange, Banana그리고 Strawberry후손이다 Fruit.
API 사용자에게 일반 유형 콜렉션이 필요합니까?
List모든 항목이있는 곳에를 사용하십시오 object.
건배.
참고 URL : https://stackoverflow.com/questions/9855693/returning-ilist-vs-icollection-vs-collection
'IT story' 카테고리의 다른 글
| curl로 PHP에 JSON을 게시하는 방법 (0) | 2020.08.05 |
|---|---|
| R-두 개의 데이터 프레임을 연결 하시겠습니까? (0) | 2020.08.05 |
| jQuery에서 라디오 버튼의 이름이 모두 같을 때 어떻게 라디오 버튼의 값을 얻습니까? (0) | 2020.08.05 |
| 디렉토리가 존재하지 않습니다. (0) | 2020.08.05 |
| EC2의 CPU 크레딧 잔고 란 무엇입니까? (0) | 2020.08.05 |