2016-05-10 2 views
4

Класс Collection<T> реализует несколько интерфейсов, один из которых - ICollection. Интерфейс ICollection имеет 2 свойства, которые не реализованы в Collection<T>.Коллекция <T> не содержит все свойства интерфейса ICollection

В C# Я считаю, что вы должны реализовать все методы и свойства интерфейса в классе, который наследует его. Итак, как класс Collection<T> позволил уйти от него?

+3

Google ** Явная реализация элементов интерфейса ** – chomba

+1

Почему вы говорите, что свойства не реализованы? Я вижу их там http://referencesource.microsoft.com/#mscorlib/system/collections/objectmodel/collection.cs,281923b8611114ec свойства Запрос ICollection - это Count, SyncRoot и IsSynchronized, все они включены –

+1

Какие два свойства вы используете мысли не реализованы? – hatchet

ответ

7

Это называется explicitly implementing an interface. Вы можете сделать элемент невидимым извне, если ссылка на объект не преобразуется в тип интерфейса.

В контексте Collection<T>, реализующего ICollection, рассматриваемый интерфейс определяет устаревшие методы, существовавшие до того, как дженерики были введены в C#. Можно сказать, что это «старый уродливый» способ управления коллекциями.

Разработчики решили скрыть эти уродливые методы, сохраняя при этом свою функциональность вызывающему.

var x = new Collection<int>(); 
object syncRoot = x.SyncRoot; //CS1061: Collection<int> does not contain a .... 
ICollection collection = x; 
syncRoot = collection.SyncRoot; //ok 

Другой сценарий - это конфликт, обычно из-за внешних интерфейсов, которые плохо разработаны и не могут быть изменены. Пример:

interface IFile 
{ 
    void Save(); 
} 
interface IDatabaseRecord 
{ 
    void Save(); 
} 

class Customer : IFile, IDatabaseRecord 
{ 
    public void Save() 
    { 
     //what to do here? 
    } 
} 

Это может быть преодолен путем внедрения метода в явном виде:

class Customer : IFile, IDatabaseRecord 
{ 
    void IFile.Save() { } 
    void IDatabaseRecord.Save() { } 
} 

Обратите внимание, что это почти всегда код запах - это может запутать абонент в заблуждении метода нет, или вызвав неправильную реализацию (что вызвало этот вопрос в первую очередь).

+0

Спасибо, что объяснили это, а также его использование. Последнее, хотя я не могу использовать, но мы можем создать интерфейс, а затем скрыть некоторые свойства или методы аналогичным образом. –

+0

Интерфейс не имеет модификаторов доступа, он в основном как он есть. Так что нельзя скрыть участников – Bas

+0

@ Abhi.Net, я думаю, что они на самом деле не скрыты. Если у вас есть метод, который принимает «IFile» из приведенного выше сценария, и вы передаете ему экземпляр «Customer», аргумент типа 'IFile' будет иметь метод« Сохранить() ». Более того, он будет называть 'IFile.Save()', если я не ошибаюсь. –

1

Его дядя работает на рамки, и все просто смотрят в другую сторону.

Включите Collection<T> в качестве ICollection, и вы увидите, что он реализует весь интерфейс ICollection.

+0

Что вы подразумеваете под «Его дядя работает для рамки, и все просто смотрят в другую сторону»? Я уверен, что будет лучшая причина. –

+0

Nepotism. И классное различие. –

2

После прочтения ваших комментариев, проблема заключается в том, что эти свойства Явное implementated, как вы можете заметить here:

bool ICollection.IsSynchronized 
{ 
    get { return false; } 
} 

Обратите внимание, что это не является общим свойством, как:

public bool IsSynchronized 
{ 
    get { return false; } 
} 

Это в основном означает, что имущество есть, но только когда вы произвели его как ICollection

var c = new Collection<double>(); 
var casted = (ICollection) c; 
var isSync = casted.IsSynchronized; 
+0

Комментарий снят - он работает, как вы сказали. –

+0

@ Abhi.Net рад, что работал –

+0

Одна последняя вещь, любая идея, почему в Visual Studio я вижу Коллекция : IList , ICollection , IEnumerable , IList, ICollection, IEnumerable Где, как и в этой связи Коллекция : IList , IList, IReadOnlyList

Смежные вопросы