Юнит тесты для "системного" приложения
То бишь в "главный класс" нужно передать минимум 3 совершенно не нужных параметра, а с экспортом и 4. Соответственно и количество лишних интерфейсов возрастает.
В общем, KISS - пошел нафиг.
Насчёт ненужных я бы поспорил. И насчёт нарушения KISS. Если компрессор и мувер не передаются снаружи значит что? Значит класс такой "умный" что сам знает как их сделать. Во-первых это сложнее чем получить их снаружи. Во-вторых это а. дополнительная ответственность и б. нарушение open-close. Аж две буквы из SOlid поломали.
Аж две буквы из SOlid поломали.
У меня есть одна проблема - не люблю слепо следовать догмам. Не люблю делать универсальных монстров и стрелять из пушки по воробьям.
Если для экспорта еще как то можно представить себе изменения, то для компрессора и мувера - довольно сложно. Вполне достаточно того, что они вынесены в отдельный класс.
Ну и делать конструкторы вьювмоделей с параметрами для ВПФа, тоже не очень хорошо.
Тем более, что прога не идет в промышленную эксплуатацию на многие годы.
Ну и делать конструкторы вьювмоделей с параметрами для ВПФа, тоже не очень хорошо.
Почему это?
Тем более, что прога не идет в промышленную эксплуатацию на многие годы.
Насколько я понимаю, в твоем случае речь идет о тестовом задании. Так вот при выполнении тестового задания от тебя хотят увидеть а) понимание технологии юнит-тестирования и б) красивое решение, желательно по SOLID.
Почему это?
Добавь в подобную конструкцию еще параметры 
<Window.DataContext>
<local:CustomViewModel />
</Window.DataContext>
...
<Window.Resources>
<local:MyViewModel x:Key="MyViewModel"/>
</Window.Resources>
<Grid DataContext="{StaticResource MyViewModel}">
</Grid>
<pre>
от тебя хотят увидеть
Скорее услышать. Времени то челу дали всего час. Кто то за час всё сделает?
Добавь в подобную конструкцию еще параметры
Ну просто инициализируешь ViewModel не в XAML, а в code behind, а именно:
InitializeComponent();
DataContext = new CustomViewModel(what-ever);
не вижу в этом никакой проблемы.
Скорее услышать. Времени то челу дали всего час. Кто то за час всё сделает?
Час конечно маловато. Но подход увидеть вполне можно.
Ну просто инициализируешь ViewModel не в XAML
Получается что следуя одному принципу мы закрываем другие.
Не могу уже вспомнить конкретную проблему, но пришлось специально убирать все параметры из конструктора. Не всегда можно code behind пользовать
Но подход увидеть вполне можно.
Ну сделай эксперимент, что получится сделать за час. Даже на своём компе. Главное - не копипастить
Мне вот тоже интересно стало, правда забыл глянуть что за час сделал. Но я и не собирался на скорость, что то писать - совершенно бессмысленное занятие.
Получается что следуя одному принципу мы закрываем другие.
Не понял, что мы закрываем?
Не могу уже вспомнить конкретную проблему, но пришлось специально убирать все параметры из конструктора. Не всегда можно code behind пользовать
Не встречал еще ситуации, когда нет code behind.
Если у тебя есть элегантный способ передать настройки во ViewModel, то было бы интересно посмотреть на этот способ. А то я эля таких ситуаций использую параметры контруктора :)
Ну сделай эксперимент, что получится сделать за час.
Честно говоря, мне лень :) Думаю, что в течении дня я бы сделал то задание.
То бишь в "главный класс" нужно передать минимум 3 совершенно не нужных параметра, а с экспортом и 4. Соответственно и количество лишних интерфейсов возрастает.
Не надо. Технологии WhiteBox, инектирование, подмена переменных класса во время выполнения. Это можно делать даже для приватных переменных. Но переменные можно делать наследуемыми и тестировать наследников класса с дополнительными сеттерами.Есть много способов внедрить мок вместо реального обьекта. А вот если нельзя, значит в классе проблемы. И функциональный и инитиализатионных код свален в одну кучу.
Не понял, что мы закрываем?
Ну хотя бы инициализацию из ХАМЛа. Как передать во вьюв-модель из ХАМЛа что-то кроме строки я не знаю.
Не встречал еще ситуации, когда нет code behind.
Тоже было до поры до времени, пока более сложный UI не понадобился.
Если у тебя есть элегантный способ передать настройки во ViewModel
Они просто идут вторым шагом, через сервис например или через сообщения.
Думаю, что в течении дня я бы сделал
Я тоже так думал, но не получилось. Там проблем больше чем вначале думаешь.
Но возьми даже 1/8 часть готового приложения, что это будет в итоге?
Во-вторых это а. дополнительная ответственность
Вот другая проблема есть, решение которой мне совершенно не нравиться, но пока не могу придумать лучше.
Есть у меня сообщение о добавлении файла в каталог. Его нужно обработать как можно быстрее, поэтому сообщение просто записывается в очередь.
Также есть отдельный поток который извлекает сообщения из очереди и затем уже делает с ними нужные операции, которые могут быть достаточно долгими.
Каждая операция реализована как вызов функции из дополнительного класса. Но вот эти все вызовы расположены в одном месте и они все разные.
С одной стороны это файловый операции, а с другой стороны, добавление новых элементов в UI и их сохранение.
Хотелось, хотя бы отделить файловые операции и UI, только как тогда информировать нужный UI элемент об ошибке.
Ну так и DI можно также делать
Если речь идёт о DI Container/Frameworks, то я их пока не переношу.
Когда всё приложение так построено, разобраться в его работе очень сложно.
Так поставил точку останова в конструкторе и знаешь кто и откуда вызвал. А с контейнером поди еще найди как эта инстасе получается т откуда пришел вызов.
Ты как-то не так понимаешь DI
Может быть. У меня есть просто различия, когда нужно, а когда нет. А не только - исключительно всё на интерфейсах внутри, а снаружи вся имплементация.
Ну зачем мне ещё добавлять "интерфейс компрессии файла" и выводить его наружу? Только для того, что может быть когда то, кто то захочет его имплементировать по другому, оставив при этом и старую версию.
Хочешь менять - меняй, всё в отдельном классе. Когда понадобится вторая имплементация, можно будет сделать, но никак не раньше того, чем вероятно может понадобится или понадобилось.
В данном случае - вероятность изменений практически нулевая.
Ну зачем мне ещё добавлять "интерфейс компрессии файла" и выводить его наружу?
Ну тут есть несколько моментов:
1) для того, чтобы код был тестируемым.
2) чтобы класс отвечал только за то, чем он занимается. И не занимался 2-мя, 3-мя и более вещами. Single Responsibility.
3) расширяемость
У меня есть просто различия, когда нужно, а когда нет.
Ну просто для тебя "нужно" - это только расширяемость :) Но на самом деле расширяемость - это просто побочная плюшка :D