Подобного рода «проверочный код» регулярно просачивается в продакшн-код.
В production коде я пользуюсь профайлером.
если бы вам не надо было реальное использование, вы бы написали тест
Я и написал тест для себя, но с удобной мне обёрткой.
Собственно, весь смысл враппера в том, чтобы не знать, что мы вызываем.
Смысл враппера (он же адаптер и обёртка) в том, чтобы адаптировать интерфейс объекта к требованиям системы. А вот смысл прокси как раз служить прозрачной заменой.
Ко второму, очевидно. Вы же знаете интерфейс класса, который используете.
Да, но к динамическому типу данных я могу добавить любые поля, методы и т.д. и узнать об ошибке только в runtime. Даже в Visual Studio я пишу «наугад». Так что, скорее всё-таки первое.
Вы свою задачу тоже решаете не встроенными средствами языка, а через Reflection, который встроенное средство платформы.
Говоря язык, я подразумевал платформу, т.к. в языке нет даже средств вывода и обсуждать его отдельно нет смысла. Уверен вы поняли меня сразу или в платформе есть средства для быстрого и легкого создания «динамических прокси»?
При чем тут сторонние средства?
Думаю из предыдущего вопроса понятно причём.
А в чем была цель? Если вы хотели получить тестовый код, то он у вас слишком хрупкий.
Javascript тоже очень хрупкий, хотя mainstream. Недостаток надёжности (который свойственен любой динамике), компенсируется удобством использования и прозрачностью кода тестов.
У вашего кода есть крупный недостаток: он не type-safe.
Не вижу в этом крупного недостатка для проверочного кода.
Для обертки вокруг reflection это оправданно, для обертки вокруг класса с известным во время компиляции публичным интерфейсом — нет.
К чему относиться, описанный динамический класс?
Такие вещи «традиционно» делаются через «динамические прокси».
Отвечал уже не раз, но повторюсь:
В языке нет встроенных средств, чтобы быстро и легко решить эту задачу через динамические прокси;
«Прибегать к помощи сторонних средств я не хотел», т.к. задача не настолько сложна и магия в runtime мне не нужна;
Динамические прокси успешно использую в production, цель была не в использование прозрачной замены (например, достаточно попробовать передать wrapper в метод принимающий объект исходного типа, чтобы понять недостаток предложенного подхода).
Ещё есть LinFu, PostSharp, Unity.Interception и т.д. Все они попадают под определение «сторонних средств», в топике я написал, что не отказался от их использования целенаправленно.
Кстати если вызывать методы не через ревлекшн а через экспрешны будет значительно быстрее.
Да я знаю, ещё быстрее сформировать делегат через Delegate.CreateDelegate, но, думаю, это не критично для не production кода.
1. Сейчас по-лучше, но не намного;
2. Не изменилось;
3. Аналогично первому и то из-за того, что в России становится всё больше и больше специалистов;
4. Пару томов добавить точно ещё можно)
5. Версия 2007 из коробки работала только в IE. Сейчас круг браузеров расширился. Вёрстка практически такая же.
А пример кода в статье мне нравится – мне кажется что по сути дела можно попробовать как-то контролировать эту “динамическую подмену” в IoC-контейнере и тем самым профилировать определенные участки кода. (Хотя профиляторы тоже никто не отменял.)
Мысль конечно интересная, но думаю, что без прокси, прозрачная «динамическая подмена» вряд ли возможна. Хотя может в каком-нибудь LinFu уже есть решение.
Да, я в курсе и про интеграцию с COM и про делегаты. В коде я постарался сделать акцент на бизнес-логике и спрятать служебный код. Можно смотреть на это как на «почти АОП».
Кстати, большинство вешает отправку по Enter только на поле пароля (если капчи нет). Иногда возвращаешься на поле логина для того, чтобы исправить ошибку, жмёшь Enter и тут fail.
В production коде я пользуюсь профайлером.
Я и написал тест для себя, но с удобной мне обёрткой.
Смысл враппера (он же адаптер и обёртка) в том, чтобы адаптировать интерфейс объекта к требованиям системы. А вот смысл прокси как раз служить прозрачной заменой.
Да, но к динамическому типу данных я могу добавить любые поля, методы и т.д. и узнать об ошибке только в runtime. Даже в Visual Studio я пишу «наугад». Так что, скорее всё-таки первое.
Говоря язык, я подразумевал платформу, т.к. в языке нет даже средств вывода и обсуждать его отдельно нет смысла. Уверен вы поняли меня сразу или в платформе есть средства для быстрого и легкого создания «динамических прокси»?
Думаю из предыдущего вопроса понятно причём.
Javascript тоже очень хрупкий, хотя mainstream. Недостаток надёжности (который свойственен любой динамике), компенсируется удобством использования и прозрачностью кода тестов.
Не вижу в этом крупного недостатка для проверочного кода.
К чему относиться, описанный динамический класс?
Отвечал уже не раз, но повторюсь:
Ещё есть LinFu, PostSharp, Unity.Interception и т.д. Все они попадают под определение «сторонних средств», в топике я написал, что не отказался от их использования целенаправленно.
Да я знаю, ещё быстрее сформировать делегат через Delegate.CreateDelegate, но, думаю, это не критично для не production кода.
2. Не изменилось;
3. Аналогично первому и то из-за того, что в России становится всё больше и больше специалистов;
4. Пару томов добавить точно ещё можно)
5. Версия 2007 из коробки работала только в IE. Сейчас круг браузеров расширился. Вёрстка практически такая же.
Мысль конечно интересная, но думаю, что без прокси, прозрачная «динамическая подмена» вряд ли возможна. Хотя может в каком-нибудь LinFu уже есть решение.
Замерами Thread.Sleep(TimeSpan.FromSeconds(rand.Next(5)));? Это действительно интересно?
Дело в том, что это практически «такой же подход», так что сравнивать можно только названия.
Отличное высказывание, чем-то отдалённо напоминает «Горе от ума»…