Здравствуйте, NetDeveloper, Вы писали:
ND>Второй вариант проще поддерживать в коде.
Первый вариант в обще странный какой-то. Опять же с точки зрения многопоточности будет lock на статическом методе. В отличии от второго подхода.
Здравствуйте, Gattaka, Вы писали:
G>Опять же с точки зрения многопоточности будет lock на статическом методе. В отличии от второго подхода.
Или я ошибаюсь, или ты ошибаешься
Здравствуйте, _NN_, Вы писали:
_NN>В силу отсутствия глобальных псевдонимов типов в C# задался вопросом как лучше сделать.
А у TA и TB есть ограничения по базовым типам?
Если да и TA и TB — не структуры, то я бы сделал не-generic SomeBase, который принимал бы базовые типы, в наследниках добавлял бы свойство, которое явно кастило бы к нужному типу, генерик-параметры вообще бы не использовал.
Довольно кривое решение, но оно работает в случае, когда надо отнаследоваться от SomeSpecific и подсунуть наследника от X или Y.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Gattaka, Вы писали:
G>>Опять же с точки зрения многопоточности будет lock на статическом методе. В отличии от второго подхода. S>Или я ошибаюсь, или ты ошибаешься S>Нету там lock, но это меньшая из проблем
Ну и как синхронизация происходит при обращении к статическому методу из разных потоков?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>В силу отсутствия глобальных псевдонимов типов в C# задался вопросом как лучше сделать.
S>А у TA и TB есть ограничения по базовым типам?
Ограничений нет.
S>Довольно кривое решение, но оно работает в случае, когда надо отнаследоваться от SomeSpecific и подсунуть наследника от X или Y.
От SomeSpecific наследоваться не потребуется.
Здравствуйте, Gattaka, Вы писали:
S>>А зачем там синхронизация, если нет разделяемого состояния? G>А откуда вы знаете что нет? И тем более компилятор откуда знает?
Как насчёт варианта "потому что блокировки нет в коде"?
Рантайм использует блокировки для static-конструкторов, это да. Для всего остального — только по пожеланиям трудящихся.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Gattaka, Вы писали:
G>>А чем не угодил вариант:
G>>
G>>b = new SomeGeneric<X, Y>(new X(), new B());
G>>
_NN>Тем, что нужно каждый раз это писать как бы.
Да, но код становится проще для понимания. Не вводится никаких дополнительных сущностей. Ты сразу видишь что происходит. Тебе не нужно лезть в Create или какой-то мутный пустой класс или что хуже синоним, как предложили выше.
Опять же почему был введен дженерик если приходится вводить тип обрезающий дженерик до обычного не дженерик класса? Это оправдано?
Здравствуйте, _NN_, Вы писали:
_NN>В силу отсутствия глобальных псевдонимов типов в C# задался вопросом как лучше сделать.
А я за третий вариант:
class SomeSpecific
{
public static SomeSpecific<X, Y> Create(X x, Y y) {return new SomeSpecific(x, y); }
public static SomeSpecific<X, Y> Create() {return Create(new X(), new Y()); }
}
class SomeSpecific<X, Y> {...}
Этот вариант особенно ок, если есть вполне реальные шансы, что нужно будет создавать объекты с не дефолтными параметрами. В этом случае мы толком и не создаем дополнительных абстракций, а просто используем вполне распространенный трюк для обхода ограничения C#, который не умеет выводить обобщенные параметры при вызове конструктора.
G>Да, но код становится проще для понимания. Не вводится никаких дополнительных сущностей. Ты сразу видишь что происходит. Тебе не нужно лезть в Create или какой-то мутный пустой класс или что хуже синоним, как предложили выше.
Но тогда использование не очень..
G>Опять же почему был введен дженерик если приходится вводить тип обрезающий дженерик до обычного не дженерик класса? Это оправдано?
Оправданно.
Там общий интерфейс плана
interface IConvertible<X,Y> { }
Могу предложить аналогию с Dictionary<TKey, TValue>.
Часто я пишу код
using SpecificDictionary = Dictionary<string, string>;
Но это работает в пределах файла и вытащить наружу никак.
Я уже
Здравствуйте, SergeyT., Вы писали:
ST>Здравствуйте, _NN_, Вы писали:
_NN>>В силу отсутствия глобальных псевдонимов типов в C# задался вопросом как лучше сделать.
ST>А я за третий вариант:
ST>
ST>class SomeSpecific
ST>{
ST> public static SomeSpecific<X, Y> Create(X x, Y y) {return new SomeSpecific(x, y); }
ST> public static SomeSpecific<X, Y> Create() {return Create(new X(), new Y()); }
ST>}
ST>class SomeSpecific<X, Y> {...}
ST>
ST>Этот вариант особенно ок, если есть вполне реальные шансы, что нужно будет создавать объекты с не дефолтными параметрами. В этом случае мы толком и не создаем дополнительных абстракций, а просто используем вполне распространенный трюк для обхода ограничения C#, который не умеет выводить обобщенные параметры при вызове конструктора.
Зачем это городить если уже есть готовое решение в виде IoC контейнеров разнообразных. Опять же как тестировать ваш код со статическими методами?
Здравствуйте, Gattaka, Вы писали:
G>Зачем это городить если уже есть готовое решение в виде IoC контейнеров разнообразных. Опять же как тестировать ваш код со статическими методами?
А зачем это тут ?
Чем плохи статические методы ?
