0

Я создаю собственную коллекцию, которая инкапсулирует ConcurrentDictionary. Я нашел много информации об инкапсуляции/наследовании из общей коллекции, но ничего конкретного для параллельных коллекций. Вот фрагмент кода моего базового примера, за которым следуют некоторые общие вопросы.Наследование/инкапсуляция параллельной коллекции C#

class ItemCollection 
{ 
    private ConcurrentDictionary<string, Item> Collection;   

    public ItemCollection() { Collection = new ConcurrentDictionary<string, Item>(); } 

    public bool TryAdd(string webId, string name) { return Collection.TryAdd(webId, new Item(name)); } 
    public bool TryAdd(string webId, Item item) { return Collection.TryAdd(webId, item); } 
    public bool TryUpdate(KeyValuePair<string, Item> entry, Data data) 
    { 
     Item newItem = entry.Value; 
     newItem.AddData(data);    
     return Collection.TryUpdate(entry.Key, newItem, entry.Value); 
    } 
} 
  • инкапсулированы параллельные коллекции в этой манере приемлемые, или это перемещение в область создания собственной поточно-коллекции из общей коллекции?
  • Является ли обычная коллекция потокобезопасной?
  • Является ли наследование параллельной коллекции когда-либо приемлемой? Как и так class ItemCollection : ConcurrentDictionary<string, Item>, и если да, то каковы некоторые рекомендации, похожие на this для наследования от несовпадающих коллекций.
  • Как вы реализуете методы пересылки для таких методов, как Select? Я попробовал ряд изменений, как следующее, но не может заставить его работать:

public IEnumerable<TResult> Select<ItemCollection, TResult>(this ItemCollection source, Func<KeyValuePair<string, Item>, TResult> selector) { return Collection.Select(selector); }

Если я наследовать ConcurrentDictionary это приводит к реализации как enter image description here

+0

Проверить [Переопределение методов расширения LINQ] (http://stackoverflow.com/questions/2705864/overriding-linq-extension-methods) – sll

ответ

1

Вопрос граничит на «слишком широком». Тем не менее, некоторые базовые ответы могут быть предоставлены. Для более подробной информации вам придется сузить свой вопрос (-ы) дальше, занимаясь меньшими, более конкретными проблемами одновременно и предпочтительно представляя эти вопросы индивидуально.

В том же время:

инкапсулированы параллельные коллекции в этой манере приемлемые, или это перемещение в область создания собственной поточно-коллекции из общей коллекции?

«Приемлемый» представляет собой широкое понятие, но и hellip; да, нет ничего принципиально неправильно с подходом.

Является ли обычная коллекция потокобезопасной?

«Потоковый сейф» - это неопределенный термин. Но в целом я бы сказал «да». Ваш класс не поддерживает какое-либо свое состояние вообще, вместо этого делегирует все состояние классу, который равен потокобезопасным. Так что для обычных проблем безопасности потоков, состояние класса должно быть в порядке.

Обратите внимание, что метод TryUpdate() также изменяет переданный объект, который является , а не выполненным поточно-безопасным способом. Но это больше касается безопасности потока этого объекта, а не вашей коллекции.

Является ли наследование одновременной коллекции когда-либо приемлемой? Подобно классу ItemCollection: ConcurrentDictionary, и если да, то каковы некоторые рекомендации, аналогичные этому для наследования от несовпадающих коллекций.

Это всегда «приемлемо» для наследования непечатаемого класса.Является ли это полезным, чтобы сделать это другое дело. Наследование наиболее полезно, когда унаследованный класс имеет полезные защищенные и/или виртуальные члены, которые производный класс может использовать, чтобы фактически продлить или иным образом изменить поведение унаследованного класса.

В противном случае методы расширения часто являются лучшим подходом.

В любом случае, я бы не ожидал, что руководство по наследованию коллекций будет сильно отличаться, если вообще зависит от того, является ли коллекция потокобезопасной или нет.

Как вы реализуете методы пересылки таких методов, как Select? Я попробовал ряд вариаций, таких как следующие, но не может заставить его работать:

«Методы, такие как Select()» реализованы как методы расширения, и полагаться на сам объект, реализующий IEnumerable<T> (для некоторых таких методов , IEnumerable достаточно хорош). Если вы хотите, чтобы ваша пользовательская коллекция могла использовать эти методы, вам нужно будет реализовать соответствующий интерфейс для методов (-ов) расширения, которые вы хотите использовать с вашим классом.

Естественно, что при реализации интерфейса вы можете делегировать фактическую операцию в инкапсулированную коллекцию.

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