А почему нельзя так? switch(variable)
{
case 1:
case 2:
Console.WrileLine("case 1");
Console.WrileLine("case 2");
break;
default:
Console.WrileLine("default");
break;
}
Я замечал интересную закономерность: чем меньше человек знает сокращений вроде SOLID, DRY, KISS, YAGNI, я уж молчу про более сложные вещи, тем больше в коде говна. Хотя казалось бы… всё же так просто и кому нужны аббревиатуры и смыслы под ними скрывающиеся.
Выбросьте стандартный говно-SerialPort из FCL. Напишите свой через WinAPI. Там только одной структурой манипулировать надо — DCB и пару функций протащить. Работать будет многократно быстрее и все слипы нелепые можно будет убрать.
Мой посыл: 200-500мс на мобилке не могут блёкнуть — это серьёзный продолб, если на UI. А кто сказал про 100мс? Даже фрэймворки иногда не обязательно использовать, чтобы увидеть адские тормоза. Например, можно заюзать на одной View под WinPhone 5-8 стандартных WPF-конвертеров и наслаждаться лютыми тормозами на UI. Иногда не то что фрэймворки тормозят, иногда то, что из пакета тормозит.
Если решились на самописное, то писать надо правильно. Кто по вашему разрабатывает фрэймворки, не люди? Нормальная команда может осилить практически любой фрэймворк (в пределах разумного).
Почти всегда можно. Другое дело, что нам не всегда следует удовлетворять SRP. Всё зависит от вероятности изменений по тем или иным аспектам, а вероятности эти обычно определяются эвристически. Невозможно везде удовлетворять SRP и собсна делать код PURE SRP.
p.s. Ну, не буду утверждать, что можно в 100% случаев подсчитать кол-во обязанностей, но хотелось бы увидеть класс, где это невозможно.
Верно. Когда есть множественное нарушение SRP. Понятие обязанности класса в целях оценки удовлетворения SRP заключается в количестве причин для изменения класса, где причинами являются акторы или аспекты изменений. На самом деле, кол-во ответственностей класса можно всегда подсчитать конкретно.
так как в самом очевидном месте всех необходимых зависимостей нет. Уж поверьте, я был бы крайне огорчен, пропустив любую из этих зависимостей, например, при рефакторинге. До вашей переделки это было бы невозможно.
Рефакторинг этих ViewModel вообще никак не зависит от этих зависимостей, мы от этого ни разу не пострадали. Это стабильные зависимости и в ближайшие годы они никуда не уедут и наблюдать их в конструкторе никому в нашем проекте не интересно, видимо, вам было бы интересно по соображениям о мифических плюсах, которые никогда не пригодятся.
Мало того, теперь после конструирования получается неполноценный объект: ему еще надо инициализировать свойства. А как вишенка на торт в класс добавлены атрибуты, дающие жесткую привязку к MEF.
Всё равно придётся прописывать ImportingConstructor и другие атрибуты специфичные для MEF. Как от этого избавляться? Отгораживать полностью MEF?
Если нет нотификаций о прогрессе как таковых, то как вы его отображаете?
Intederminate Progress Bar. Чтобы пользователь понимал, что приложение не зависло наглухо и не дать затыкать UI.
Кучи модальных диалогов не нужны, как и подтверждения действий пользователя. Смотрите хоть у Купера, хоть у Раскина. Подтверждения объективно требуют только необратимые операции (фарш невозможно провернуть назад). И если такого у вас много, то это весьма специфический проект.
Именно так, у нас специфичный проект. Вообще я зачастую акцентирую внимание на том, что не надо выдвигать догмы, мне нравится Марк Симан, но считаю его объективным недостатком — догматизм.
Не вижу ничего сложного. Мои ViewModel оказываются проще ваших
За счёт чего? Куча лишних классов лучше одного, с помощью которого можно показывать прогресс бар?
Итак, у вас есть зависимости, которые не нравятся вам самому.
Что значит не нравятся, откуда вы это взяли?
По моему мнению лучший способ сделать зависимость явной — сделать ее параметром конструктора.
В статье идёт речь как раз о том, что утилитарные зависимости бессмысленно вытаскивать в конструктор, поскольку ничего они для чтения хорошего не несут. Никто на нашем проекте ни разу не ощутил боли от того, что мы вынесли их из конструктора.
А в чем специфика? Вам досталось такое легаси, это явное требование заказчика, это навязано каким-нибудь фреймворком? По-настоящему безнадежен только второй вариант.
Специфика в том, что есть куча операций, длительность которых невозможно заранее рассчитать (с устройствами мы работаем очень много, которые никаких нотификаций о прогрессе не поддерживают). И есть куча модальных диалогов, просто потому что они нужны в ПО, не понимаю, что здесь объяснять… они вызваны необходимостью запрашивать подтверждения действий у пользователя.
1) Модальные диалоги — по возможности выпилить совсем как наихудшую разновидность фриза. Там, где выпилить не удается, оставить зависимость в конструкторе — такая часть Control Flow должна быть явной.
Выпилить невозможно, потому что это не разновидность фриза, а необходимые запросы к пользователю. В конструкторе ничего оставлять не надо, потому что нафиг не надо, зачем и кому надо смотреть на наличие этой зависимости — непонятно, они всё равно есть почти везде.
2) Агрегатор событий можно заменить на конкретные источники событий, они скажут гораздо больше, чем агрегатор, который сам по себе является разновидностью Service Locator со всеми его проблемами.
Проблемы зависят от контекста. У нас проблем нет.
3) Прогресс — если это не подразумевает фриз, то реализовать как отдельный стек MVVM, т.е. длительные задачи, неважно кем инициированные, публикуются отдельной моделью, над которой есть свои ViewModel и View для отображения прогресса. Ваша ViewModel должна только вызвать метод собственной модели. Если же нужен именно фриз, можно сделать это частью интерфейса сервиса модальных диалогов.
Святая корова, зачем так сложно? Плодить чего-то там, если можно всего этого не делать?
switch(variable)
{
case 1:
case 2:
Console.WrileLine("case 1");
Console.WrileLine("case 2");
break;
default:
Console.WrileLine("default");
break;
}
А насчёт подписи: откуда вы сертификат для подписи возьмёте?
Правда адекватным бленд стал только в новой версии.
Если решились на самописное, то писать надо правильно. Кто по вашему разрабатывает фрэймворки, не люди? Нормальная команда может осилить практически любой фрэймворк (в пределах разумного).
p.s. Ну, не буду утверждать, что можно в 100% случаев подсчитать кол-во обязанностей, но хотелось бы увидеть класс, где это невозможно.
Рефакторинг этих ViewModel вообще никак не зависит от этих зависимостей, мы от этого ни разу не пострадали. Это стабильные зависимости и в ближайшие годы они никуда не уедут и наблюдать их в конструкторе никому в нашем проекте не интересно, видимо, вам было бы интересно по соображениям о мифических плюсах, которые никогда не пригодятся.
Всё равно придётся прописывать ImportingConstructor и другие атрибуты специфичные для MEF. Как от этого избавляться? Отгораживать полностью MEF?
Intederminate Progress Bar. Чтобы пользователь понимал, что приложение не зависло наглухо и не дать затыкать UI.
Именно так, у нас специфичный проект. Вообще я зачастую акцентирую внимание на том, что не надо выдвигать догмы, мне нравится Марк Симан, но считаю его объективным недостатком — догматизм.
За счёт чего? Куча лишних классов лучше одного, с помощью которого можно показывать прогресс бар?
Что значит не нравятся, откуда вы это взяли?
В статье идёт речь как раз о том, что утилитарные зависимости бессмысленно вытаскивать в конструктор, поскольку ничего они для чтения хорошего не несут. Никто на нашем проекте ни разу не ощутил боли от того, что мы вынесли их из конструктора.
Специфика в том, что есть куча операций, длительность которых невозможно заранее рассчитать (с устройствами мы работаем очень много, которые никаких нотификаций о прогрессе не поддерживают). И есть куча модальных диалогов, просто потому что они нужны в ПО, не понимаю, что здесь объяснять… они вызваны необходимостью запрашивать подтверждения действий у пользователя.
Выпилить невозможно, потому что это не разновидность фриза, а необходимые запросы к пользователю. В конструкторе ничего оставлять не надо, потому что нафиг не надо, зачем и кому надо смотреть на наличие этой зависимости — непонятно, они всё равно есть почти везде.
Проблемы зависят от контекста. У нас проблем нет.
Святая корова, зачем так сложно? Плодить чего-то там, если можно всего этого не делать?