Как лучше работать с сложными типами являющимися дженериками

314

10 августа 2017, 20:50

Есть класс:

public class Resource<T> : IGame where T : Component 
{

И например мы его как тип используем в каком то интерфейсе:

public interface IBuildResource
{
    Resource<Component> GetPath(List<Resource<Component>> RefList);
}

Приемлемой ли практикой будет писать <Resource<Component>> заместо <Resource<T>> и соотвественно делать дженериком сам интерфейс.

Или например в функциях класса реализующих этот интерфейс писать:

class BuildComponent<T> : BaseCls, IBuildResource 
{
        public Resource<Component> GetPath(List<Resource<Component>> resList)
        {
            Resource<Component> resReference = null;
            . . .
            return resReference;
        }

Answer 1

Последний пример с BuildComponent<T> скорее всего неверен, так как выглядит это примерно так:

List<int> list;
list.Remove("item");
list.Find<String>()

Обычно такие методы всё-таки имеют какую-либо связь с T

public Resource<T> GetPath(List<Resource<T>> resList) where T : Component

Честно говоря, я бы крепко подумал над вложенными Generic'ами. Их просто неудобно читать и писать. Вместо List<Resource<Component>> я бы предпочёл видеть

class ComponentList : ResourceList<Component>
{
}
class ResourceList<T> : List<Resource<T>>
{
}

Это не потребует много сил и времени, из лишнего кода - только необходимость объявить конструкторы, зато код станет на порядок чище и приятнее глазу. Исключительно субъективное мнение. Некоторые использует вместо этого алиасы, но мне кажется, что они скорее запутают, чем помогут. А типизированных макросов у нас пока нет, в отличии от того же Nemerle.