H>Тем, что надо таскать ServiceLocator — это раз, а также понять, кто и где продолбал регистрацию, если внезапно не срослось.
Продолбал регистрацию — это вопрос опыта работы с IoC. Неопытные программисты поначалу на структурах могут наколоться. А потом — норм.
Предложенный автором подход с синонимом — самое плохое решение. Читаемость кода ухудшается. Да вы экономите символы при написании инициализации. Но возникает ряд вопросов. Когда и в каких случаях использовать синонимы, а когда нет. Где эта грань? Чтобы было понятнее juniorы c помощью этой конструкции будут городить чудеса. Аля new Sometype(5,7) и new Sometype(4,5).
Вводится еще одна сущность, которая приблизит C# к тому кошмару, что творится в С++.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Gattaka, Вы писали:
G>>Опять же как тестировать ваш код со статическими методами?
H>Пишется тест, который вызывает статический метод.
Я прекрасно понимаю, что можно выкрутиться. Но зачем добавлять либо еще один метод, либо еще один фейковый тип. Либо синоним как предложил автор, если есть готовый подход. Знакомый любому нормальному программеру. Ваш код будет читаемый, сопровождаемый, простой. Самое главное простой. За счет общеупотребительнсоти IoC.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Gattaka, Вы писали:
G>>Зачем это городить если уже есть готовое решение в виде IoC контейнеров разнообразных. Опять же как тестировать ваш код со статическими методами? _NN>А зачем это тут ? _NN>Чем плохи статические методы ?
Тем что вводите еще одну сущность, не используя готовые инструменты. Увеличиваете сложность.
Здравствуйте, Gattaka, Вы писали:
G>>>Зачем это городить если уже есть готовое решение в виде IoC контейнеров разнообразных. Опять же как тестировать ваш код со статическими методами? _NN>>А зачем это тут ? _NN>>Чем плохи статические методы ? G>Тем что вводите еще одну сущность, не используя готовые инструменты. Увеличиваете сложность.
Кто сказал, что тут нужно что-то инджектить и что этим типом нельзя пользоваться? Кто сказал, что эта зависимость изменчивая? Кто сказал, что "готовый инструмент" подходит для этой задачи?
Использование готовых инструментов не по назначению — это главная причина увеличения сложности.
Здравствуйте, SergeyT., Вы писали: ST>Кто сказал, что тут нужно что-то инджектить и что этим типом нельзя пользоваться? Кто сказал, что эта зависимость изменчивая? Кто сказал, что "готовый инструмент" подходит для этой задачи?
Да, тут много недосказанностей. Но автор топика не хочет делать просто new Sometype<X,B>(new X(), new B()). А ведь этот код стоит использовать в случае отрицательного ответа на ваши вопросы. В случае пложительного — IoC.
Таким образом Create и введение синонима в любом случае отпадают.
ST>Использование готовых инструментов не по назначению — это главная причина увеличения сложности.
Утверждение не оспариваю. Напротив — согласен. В данной задаче следует по возможности оттягивать использования IoC.
Здравствуйте, Gattaka, Вы писали:
H>>Пишется тест, который вызывает статический метод.
G>Я прекрасно понимаю, что можно выкрутиться. Но зачем добавлять либо еще один метод, либо еще один фейковый тип. Либо синоним как предложил автор, если есть готовый подход. Знакомый любому нормальному программеру. Ваш код будет читаемый, сопровождаемый, простой. Самое главное простой. За счет общеупотребительнсоти IoC.
Скажите, у вас весь код так написан ?
Вместо, скажем, string.Compare(a,b) пишете там ServiceLocator.Get<IStringComparer>(a, b) ?
Здравствуйте, _NN_, Вы писали:
_NN>Скажите, у вас весь код так написан ? _NN>Вместо, скажем, string.Compare(a,b) пишете там ServiceLocator.Get<IStringComparer>(a, b) ?
Мы вобще про создание объекта говорили. Зачем передергивать? string.Compare(a,b) — содержит в себе логику. Ничего не создает.
Давайте на чистоту, когда вы задавали вопрос у вас уже был ответ в виде синонима. И вся печаль в том, что синоним неудачное решение, повторение ошибок Си.
Вы пытались найти сторонников. Но на самом деле для C# было бы лучше не добавление синонимов, а реализация нормального встроенного IoC. (не MEF, который ни разу не IoC). Чтобы люди не говорили — "О-о-о, ради такой фитюльки IoC в проект тащить".
Здравствуйте, Gattaka, Вы писали:
G>Продолбал регистрацию — это вопрос опыта работы с IoC. Неопытные программисты поначалу на структурах могут наколоться. А потом — норм.
Это не вопрос опыта. Это вопрос размеров проекта. В большом проекте регистрация теряется легко и непринужденно в каком-нибудь стороннем модуле. И искать ее потом можно очень долго. Особенно если сторонний модуль является черным ящиком, для которого даже сорцов нет.
Happy debugging.
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, Gattaka, Вы писали:
G>>Продолбал регистрацию — это вопрос опыта работы с IoC. Неопытные программисты поначалу на структурах могут наколоться. А потом — норм.
L>Это не вопрос опыта. Это вопрос размеров проекта. В большом проекте регистрация теряется легко и непринужденно в каком-нибудь стороннем модуле. И искать ее потом можно очень долго. Особенно если сторонний модуль является черным ящиком, для которого даже сорцов нет. L>Happy debugging.
Здравствуйте, Gattaka, Вы писали:
G>Здравствуйте, _NN_, Вы писали:
_NN>>Скажите, у вас весь код так написан ? _NN>>Вместо, скажем, string.Compare(a,b) пишете там ServiceLocator.Get<IStringComparer>(a, b) ?
G>Мы вобще про создание объекта говорили. Зачем передергивать? string.Compare(a,b) — содержит в себе логику. Ничего не создает. G>Давайте на чистоту, когда вы задавали вопрос у вас уже был ответ в виде синонима. И вся печаль в том, что синоним неудачное решение, повторение ошибок Си.
Какие аргументы против ?
Т.е. в коде 'using C = System.Console;' тоже плохо ?
G>Вы пытались найти сторонников. Но на самом деле для C# было бы лучше не добавление синонимов, а реализация нормального встроенного IoC. (не MEF, который ни разу не IoC). Чтобы люди не говорили — "О-о-о, ради такой фитюльки IoC в проект тащить".
Пример в студию.
Я думаю нет встроенного потому как каждому нужно что-то своё, а в встроенный не всех будет устраивать.
Здравствуйте, _NN_, Вы писали:
_NN>Какие аргументы против ? _NN>Т.е. в коде 'using C = System.Console;' тоже плохо ?
А что хорошего? Это экономия букв за счет прозрачности и понятности кода. Эту конструкцию следует использовать только при наличии конфликтов, что крайне редко происходит.
G>>Вы пытались найти сторонников. Но на самом деле для C# было бы лучше не добавление синонимов, а реализация нормального встроенного IoC. (не MEF, который ни разу не IoC). Чтобы люди не говорили — "О-о-о, ради такой фитюльки IoC в проект тащить". _NN>Пример в студию. _NN>Я думаю нет встроенного потому как каждому нужно что-то своё, а в встроенный не всех будет устраивать.
Очевидно же — тем кому не нравится будут использовать свое. Это как с Hashset — кому не нравится используют C5. Но подавляющее большенство используют стандартный.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Gattaka, Вы писали: G>>Вот поэтому микросервисы рулят.
AVK>Не, поэтому рулит статический ресолвинг.
Что такое статический резолвинг? Не понял.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Gattaka, Вы писали:
S>>>А зачем там синхронизация, если нет разделяемого состояния? G>>А откуда вы знаете что нет? И тем более компилятор откуда знает? S>Как насчёт варианта "потому что блокировки нет в коде"?
S>Рантайм использует блокировки для static-конструкторов, это да. Для всего остального — только по пожеланиям трудящихся.
А как насчет первого вызова статического метода из кучи потоков? Должен ведь конструктор типа вызваться. В какой момент снимается блокировка на инициализацию типа? Нужно ведь проверить был ли вызов конструктора типа.
Здравствуйте, Gattaka, Вы писали:
AVK>>Не, поэтому рулит статический ресолвинг. G>Что такое статический резолвинг? Не понял.
Это когда в вижаке нажал F12 на вызов конструктора и попал на определение конструктора. Очень удобно, надо сказать
На IoC свет клином не сошелся, однако.
Здравствуйте, Gattaka, Вы писали:
G>Здравствуйте, _NN_, Вы писали:
_NN>>Какие аргументы против ? _NN>>Т.е. в коде 'using C = System.Console;' тоже плохо ? G>А что хорошего? Это экономия букв за счет прозрачности и понятности кода. Эту конструкцию следует использовать только при наличии конфликтов, что крайне редко происходит.
Введение алиасов следует использовать лишь когда это себя оправдывает. На практике зачастую ее используют чтобы сократить в контексте файла обобщенные типы от многих аргументов: словари, кортежи, или их произвольные комбинации.
Здравствуйте, Gattaka, Вы писали:
G>А как насчет первого вызова статического метода из кучи потоков? Должен ведь конструктор типа вызваться. В какой момент снимается блокировка на инициализацию типа? Нужно ведь проверить был ли вызов конструктора типа.
Проверять вызов конструктора типа нужно только если метод обращается к статическим данным это раз, и для этого не требуется захватывать блокировку, это два. После вызова конструктора типа рантайм имеет всю информацию для того, чтобы удалить проверку из остальных методов, делает ли он это, мне не ведомо.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Gattaka, Вы писали:
G>>А как насчет первого вызова статического метода из кучи потоков? Должен ведь конструктор типа вызваться. В какой момент снимается блокировка на инициализацию типа? Нужно ведь проверить был ли вызов конструктора типа.
H>Проверять вызов конструктора типа нужно только если метод обращается к статическим данным это раз, и для этого не требуется захватывать блокировку, это два. После вызова конструктора типа рантайм имеет всю информацию для того, чтобы удалить проверку из остальных методов, делает ли он это, мне не ведомо.
Ну так есть ведь флажок beforefieldinit. Который сказывается на производительности. Т.е. достаточно вам только добавить статический конструктор к типу, как получаете просадку по производительности в неожиданном месте. Плюс есть соблазн работать из статического метода с другими полями, а не только создавать экземпляр. Нужно синхронизировать и т.п. Вобщем решение со статическими методами всегда выглядит не очень здорово. Лично я стараюсь избегать статических методов.
Плюс есть соблазн работать из статического метода с другими полями, а не только создавать экземпляр. Нужно синхронизировать и т.п. Вобщем решение со статическими методами всегда выглядит не очень здорово. Лично я стараюсь избегать статических методов.
