SOLID и пользовательский интерфейс?

Question

Я стараюсь следовать принципам SOLID. Но каждый раз, когда речь заходит о пользовательских интерфейсах, я нахожу, что существует определенное трение между неуклюжими экранами гибридных, агрегированных данных, требуемых клиентом, и хорошими принципами единой ответственности.

Теперь это можно разделить и властвовать различные биты и куски типичного пользовательского интерфейса на классы одной ответственности, но тогда вы бежите во все виды интересных конструктивных вопросов, потому что так называемые «отдельные» куски gui на самом деле часто оказываются разными представлениями одного и того же общего состояния или, по крайней мере, частичными представлениями о перекрывающемся состоянии.

Я часто заканчиваю тем, что скрепил довольно неуклюжие классы контроллеров для моих представлений, которые не очень СОЛИДНЫЕ, но это довольно противоречивая практика кодирования, и это меня немного беспокоит. Просто кажется, что сложность его разделения не стоит.

Итак, как вы справляетесь с этим?

Answer 1

Вы изучали presentation patterns (неполные труды Мартина Фаулера)? Я склонен использовать модель представления для сложных представлений и автономного представления для тривиальных представлений. Модель презентации дает вам гибкую настройку, и вы можете легко протестировать эти классы.

Answer 2

Я думаю, вы в значительной степени правы. Представление данных, возможно, должно быть «громоздким экраном гибридных, агрегированных данных», если это то, что хороший пользовательский опыт диктует для вашего приложения. Для пользовательского интерфейса удобство использования интерфейса более важно, чем пытаться придерживаться принципов проектирования кодирования. Принципы разработки кода не должны определять способ работы или работы пользовательского интерфейса. Затем вы просто получаете жесткие формы и взгляды, которые имеют смысл для кода. Сделайте то, что имеет смысл для пользователя.

Это, как говорится, шаблон MVC/MVP, как упомянуто выше, все еще может помочь. Отделите представление от ведущего. Таким образом, вы все равно можете изолировать свое представление и сохранить SRP для представления. Ваш ведущий - это тот, который должен был бы нарушить SRP и иметь несколько причин для изменения.