Вот один сценарий. Моя ViewModel должна получать данные и отвечать на команды фильтра из пользовательского интерфейса. Я создаю ViewModel, чтобы быть составной по структуре. То есть дочерние классы, которые имеют доступ к закрытым членам ViewModel, выполняют линейные задачи, такие как обработка фильтрации. У меня также может быть другой дочерний класс, который выполняет необходимую логику для выбора элементов на основе критериев. Вы поняли идею. Как только ViewModel выполняет определенные функции, охватывающие несколько методов, он может стать хорошим кандидатом для делегирования дочернему классу. Дочерние классы остаются частью основной ViewModel, так что это всего лишь способ уменьшить размер ViewModel и упростить модульное тестирование этих линейных операций.
т Мартин говорит:«Никогда не должно быть более одной причины для изменения класса».
Давайте рассмотрим класс ViewModel, который связан с View. Возможно (или даже вероятно), что ViewModel состоит из свойств, которые на самом деле не связаны друг с другом. Для небольших представлений ViewModel может быть достаточно последовательным, но, хотя приложение становится все более сложным, ViewModel будет предоставлять данные, которые могут быть измененыпо разным и не связанным причинам.
Должны ли мы беспокоиться о принципе SRP в случае класса ViewModel или нет?