Здравствуйте, es3000, Вы писали:
E>Я ищу способ написать "хороший", поддерживаемый, расширяемый код. E>Чтобы в нем разные зоны "ответственности" были разделены. E>В этом есть здравая идея.
Это правильно, главное не переборщить
E>Но на практике сталкиваешься с тем, что разделить-то толком и не получается. E>Все равно получается (хоть "чистая архитектура", хоть MVP, хоть MVVP), что все друг на друга "завязано".
Как раз наоборот, везде все развязано.
E>Смысл разделения в чем? E>В том, чтобы при изменении одной части кода, не приходилось менять другую часть кода. E>Например, представьте тот же Wizard. E>Мы хотим отвязать логику отображения последовательности форм от конкретных форм-представлений. E>Например, чтобы иметь возможность позже сделать формы красивее. E>И получается, что мы не можем этого сделать!
Почему не можем? Сделали же — класс WizardFlow, он знает про порядок страниц, но ничего не знает про вид этих страниц.
Изменяй страницы сколько угодно.
Абстракция понадобилась — ты ее выделил.
E>Так как логика отображения форм заложена в Презентере, а Презентер жестко завязан на формы. E>Как их отвязать?
Зачем отвязывать?
Для веба понятно, там презенетер создал вьюмодель, которая затем выводится разными способами.
Вьюмодель — это просто числа и строки, которые нужно вывести. Затем из нее получается веб-страница для просмотра, или веб-страница для печати, или pdf-файл и т.д.
Как ты представляешь презентер в WinForms, отвязанный от контролов.
Именно абстрагированный презентер, а не просто как вспомогательный класс в примере с визардом.
Ты можешь абстрагировать все от всего. Получишь абстракцию на абстракции.
Твой простой код превратится в огромную лапшу (трудноподдерживаемую)
Не обязательно делать это отдельными классами, потому что ты получшь два класса, но очень сильно связанных. С ними будет сложнее работать.
Важнее понимать, где код модели, где код презентера, а где код вью и т.п. Чтобы, если вдруг тебе действительно понадобится с помошью одного презентера управлять несколькими формами, ты смог это сделать. Мог бы выделить вспомогательные классы для работы (и упрощения) презентера (например, WizardFlow)
На самом высоком уровне приложения у тебя будет отдельно модель (бизнес-логика), отдельно вью (формы), отдельно посредник между ними (app).
А вообще, главное — SRP из SOLID. Остальное все само сделается.
Q>Обычно, когда говорят про отсутствие зависимости или слабую зависимость, то имеют в виду зависимость от конкретной реализации объекта-контрагента.
А что значит "зависимость от конкретной реализации"?
Q>Т.е. для нас объект выполняет какую-то роль, на которую мы можем полагаться. Q>Обычно такая роль оформляется в виде абстрактного интерфейса, операции которого наделены определенными ожиданиями (семантикой).
... Q>Когда говорят о минимизации зависимостей, то подразумевают, что нам не важно какой именно человек сидит за кассой, лишь бы он делал то, что положено интерфейсу "кассир".
А чем семантика метода не интерфейс?
Вполне себе четкий и понятный интерфейс, или контракт.
И код, вызывающий метод, не зависит от его внутренности.
Получается, все что вызывается через методы — это можно считать независимым?
Интуитивно понятно, что нет.
Дело видимо не только в интерфейсе, а в чем то еще.
Интерфейсы изобретены очень давно.
Можно сказать, что еще в ассемблере были интерфейсы, когда передать управление можно было куда угодно, главное чтобы там, куда передается управление, выполнялось то, что ожидается.
Но ведь все равно несмотря на наличие интерфейсов, все придумывают и придумывают новые архитектуры.
Какую проблему они решают этими архитектурами?
Почему интерфейсов мало?
Здравствуйте, es3000, Вы писали: E>А что значит "зависимость от конкретной реализации"?
Когда зависимый код может работать только с одной реализаций компонента, т.е. залазит в его кишки или полагается на какие-то неочевидные аспекты поведения, зависящие от реализации компонента.
E>А чем семантика метода не интерфейс? E>Вполне себе четкий и понятный интерфейс, или контракт. E>И код, вызывающий метод, не зависит от его внутренности.
E>Получается, все что вызывается через методы — это можно считать независимым? E>Интуитивно понятно, что нет.
E>Дело видимо не только в интерфейсе, а в чем то еще.
E>Интерфейсы изобретены очень давно. E>Можно сказать, что еще в ассемблере были интерфейсы, когда передать управление можно было куда угодно, главное чтобы там, куда передается управление, выполнялось то, что ожидается.
E>Но ведь все равно несмотря на наличие интерфейсов, все придумывают и придумывают новые архитектуры. E>Какую проблему они решают этими архитектурами? E>Почему интерфейсов мало?
Интерфейс, обычно, описывается формально, в виде сигнатур методов.
Конкретно может быть метод void Sort(), из его сигнатуры не следует, что он отсортирует что-то внутри объекта.
Но человек-программист по имени метода (возможно из документации) выявляет его семантику.
Т.к. формального на уровне языке программирования подтверждения нет, то по сути — это догадка (или надежда ).
В реальности метод может отформатировать диск C:
При соблюдении семантики метода (иногда проверку правильной семантики можно выполнить с помощью контрактов, пред- и пост-условий)
он будет таки сортировать.
А вот как сортировать — это оставляется на откуп реализации. Например, там может быть пузерек или qsort.
Б>На самом высоком уровне приложения у тебя будет отдельно модель (бизнес-логика), отдельно вью (формы), отдельно посредник между ними (app).
Б>А вообще, главное — SRP из SOLID. Остальное все само сделается.
Применять SRP — трудно.
Когда задумываешься о его применении, то получается что надо каждое действие писать отдельно.
Ведь его критерий — причина изменений.
задача интересная и по сложности стремящаяся к бесконечности. визард в его худших проявлениях представляет ветвистое дерево, и давая юзеру гулять по нему туда обратно и что то менять — вы будете иметь колоссальное количество фана. вам надо четко решить что вы поддерживаете, а что — нет, если простые шаги, никогда не меняющие последующих — то можно офомить как M-V-VM -М = модель определение визарда, VM — глобальные парамтеры визарда, например, шаги + модель текущего шагa, а V — отображение текущего шага визарда + глобальная навигация по шагам + (например) — завершить в дефолтными значениями. Конечно, более красиво получится в WPF с возможностью определять визуальное представление для типа данных. Но тоже можно сделать и на формах.
максимально сухая информация о визарде — шаги. каждый шаг — модель, описывающя данные забираемы на шаге, возможно, валидация. для MVVM справедливо следующее: App = V.Bind(new VM(M)) — если поймете смысл этого, поймете MVVM.
Здравствуйте, es3000, Вы писали:
E>Я ищу способ написать "хороший", поддерживаемый, расширяемый код.
А почему ты считаешь, что "хороший" код — это обязательно какая-то модная аббревиатура? MVVM, MVC, MVP... как видишь, даже их самих — минимум три. Т.е. даже "теоретики" не могут выработать один подход.
E>Чтобы в нем разные зоны "ответственности" были разделены.
Ну "разделены" они... И ЧТО? Почему такой код сразу станет "хорошим"? Потому что теоретик, написавший многотомник "как понять MVVM", тебе это сказал?
E>Но на практике сталкиваешься с тем, что разделить-то толком и не получается.
Наконец-то дошло!! Вот именно, что в теории все горазды рисовать в воздухе квадраты, говорить о разделении... на деле есть сотня ньюансов и вообще нерешаемых мест (где практика не подходит ни под какую теорию).
Я думаю, что твоё велосипедостроение, которое ты гордо хочешь разруливать только рассуждениями теоретиков, можно легко разрешить, если ты объяснишь, что ты вообще за задачу решаешь. Не абстрактный же визард тебе нужен! Более того — если до тебя никто это не написал, не считаешь же ты себя гением (или считаешь? ), который пришёл в ИТ и научил всех "как правильно делать визарды"!
Иногда даже хардкоженое решение — наиболее простое. Потому что ЕГО МОЖНО ПОНЯТЬ. Посмотри на NSIS — тоже далеко не образчик сетапов (в плане кода), но он прост и он работает. Прежде чем залезать в абстракции "а вдруг юзер захочет...", надо собрать актуальную статистику, а хочет ли вообще? Этим страдают мелкомягкие "космические архитекторы" (про них ещё Спольски писал) — заранее абстрагировать задачу, будто они не сетап пишут, а универсальный управлятор НЛО. В результате большинство кода не просто висит мёртвым грузом, а ещё и мешает простому использованию.
Здравствуйте, es3000, Вы писали:
E>Реализовывать планируется на WinForms C#.
E>С первого взгляда кажется, что для управления логикой и последовательностью отображения окон для пользователя, надо сделать какой-то отдельный объект-Контроллер. E>Правильно?
E>Что думаете? E>Подскажите пожалуйста?
Я думаю, если мне снова придётся делать помощников, сделаю сначала рабочий интерфейс помощника без всякой логики, чтобы он мог работать сам по себе — можно вводить данные, ходить между страницами.
Добавлю события на открытие и закрытие страниц, куда буду передавать введенные данные. Это всё тривиально, но надо добавить поддержку ожидания обработки данных после того, как страница открылась, если переход на эту страницу запускает некий процесс.
Будет соблазн сделать всё это универсальным механизмом, но быстрее сделать всё конкретно под задачу — пустой интерфейс, который тем не менее умеет менять своё поведение в зависимости от выбранных пользователем параметров.
).
Вот именно, что в теории все горазды рисовать в воздухе квадраты, говорить о разделении... на деле есть сотня ньюансов и вообще нерешаемых мест (где практика не подходит ни под какую теорию).
