2009-12-23 3 views
1

Я работаю над проблемой транспортировки и не могу прыгнуть с этой препятствия. Я не могу преобразовать производный класс StopsVisited в его базовый класс Остановки. Базовый класс Stops - это коллекция Stop. Полученный класс StopsVisited представляет собой набор StopVisited.Невозможно преобразовать производный класс в базовый класс

Элемент StopVisited имеет значение Stop (определения не показаны).

У меня есть обходное правило, в котором я просто получаю StopsVisited из Stops, но дженерики дают мне больше свободы. Я попытался уменьшить его до самой простой формы.

Base

public abstract class Stops<T> where T : Stop 
{ 

} 

производный

public class StopsVisited : Stops<StopVisited> 
{ 

} 

Проблема:

Stops<Stop> stops = new StopsVisited(); 

дает мне ошибку

1 Не может неявно преобразовать тип «StopsHeirarchy.StopsVisited» в «StopsHeirarchy.Stops»

Любая помощь приветствуется.

+0

Если остановки - это всего лишь список объектов остановки, почему бы просто не использовать IList? – 2009-12-23 21:56:58

+1

Еще одна проблема ковариации дженериков ... см. Мой ответ здесь - http://stackoverflow.com/questions/1443341/explicit-casting-problem/1443351#1443351 – thecoop

ответ

5

StopsVisited не является подтипом Stops<Stop>; это подтип Stops<StopVisited>, что совсем другое. Я согласен с duffymo в том, что подтипирование является неправильным подходом к вашей проблеме, но конкретная функция, о которой вы просите, называется «ковариация» или «выход-безопасна» в C# 4; вы можете прочитать об этом here.

+1

Ковариация будет только для интерфейсов, а не для классов. Так что это не поможет здесь – thecoop

+0

Я бы не сказал «это не поможет». Только то, что он должен будет использовать эту функцию, поскольку она разработана, а не как он написал вопрос. –

0

C# 4.0 решает эту проблему, изменяя CLR, чтобы поддерживать ее.

А пока у вас есть интерфейс IStops (не общий) и конвертировать в него.

+1

Nope - ковариация - это только для интерфейсов, а не для классов. – thecoop

3

Лично я не использовал бы наследование, чтобы сказать, что был посещен Stop. У меня будет логический член данных, чтобы сказать, что Stop был посещен. Это похоже на двоичный атрибут - вас либо посетили, либо нет.

Наследование должно быть о разных поведении. Если вы не скажете, что посещаемый Stop каким-то образом ведет себя по-другому, я бы посоветовал не наследовать в этом дизайне.

+0

Действительно. Наследование чрезмерно используется во многих ситуациях. –

+0

Это проблема с представлением кратких вопросов. StopVisited имеет много атрибутов, которые не имеют отношения к Stop (фактическая широта/долгота при посещении, PopularOrder, фактическое ServiceTime ...). –

+0

Я бы сказал, что PopularOpder должен быть атрибутом агрегации Stops, потому что тот же Stop может участвовать в нескольких поездках. То же самое касается ServiceTime. И lat/long фиксируется независимо от того, посетили ли вы его или нет. Все еще плохой дизайн, который следует переосмыслить. – duffymo

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