Варианты использования чистой архитектуры против контроллера с функциями
Я только начал читать о чистой архитектуре, и я запутался в определениях реализации вариантов использования.
Рассмотрим класс контроллера, имеющий набор функций, который принимает T и возвращает R после выполнения некоторой логики.
interface IController {
fun usecase1(param:T) : R
fun usecase2(param:T) : R
}
теперь я могу выполнять варианты использования с экземпляром IController.
Другой способ - определить каждый вариант использования как класс и внедрить его в другие объекты, которым требуется функциональность.
class UseCase1 {
fun execute(param:T):R {}
}
class UseCase2 {
fun execute(param:T):R {}
}
каковы преимущества/недостатки между использованием вариантов использования в качестве отдельных единиц по сравнению с использованием их в качестве функций некоторого класса?
ИМО, отдельные блоки добавляют накладные расходы на строительство и закачку тогда как другой подход страдает от «проблем наследования над композицией». Какой правильный путь?
Ответы 3
В соответствии с принципом разделения интерфейсов лучше иметь отдельные интерфейсы вариантов использования для каждого случая. Это позволяет вам каким-то образом абстрагироваться от реализации варианта использования. И вы можете разделить или разделить реализацию варианта использования независимо от уровня контроллера.
Я бы почтительно рекомендовал разделить каждый вариант использования на отдельный класс. Потому что модифицируя один из них, вы будете на 100% уверены, что не тормозите другой. Но если юз-кейсов у вас много, и они небольшие, в таком случае имеет смысл сгруппировать по файлам. Но я думаю, что функции высокого порядка подходит лучше, чем набор функций в классе.
Имеет смысл создавать класс, когда у него есть состояние и поведение, но если вы создаете класс для вариантов использования, он будет без состояния, а методы вряд ли будут тесно связаны.
Но что действительно важно в соответствии с чистой архитектурой, так это разделение слоев. Неважно, как организовать хранение вариантов использования, но очень важно иметь возможность позже изменить решение независимо от других слоев.
what are the advantages/disadvantages between having usecases as separate units versus having it as functions of some class?
Если вы поместите все в контроллер, вы нарушите принцип единой ответственности. Код контроллера изменится по другим причинам, чем код варианта использования.
Например. Контроллер принимает ввод от пользователя и создает вывод для пользователя, часто с помощью ведущего. Это означает, что он считывает входные данные из моделей представлений и обновляет модели представлений. Модели представления принадлежат пользовательскому интерфейсу и будут меняться по причинам, связанным с пользовательским интерфейсом.
Варианты использования не должны зависеть от пользовательского интерфейса, если вы реализуете чистую архитектуру, и они будут меняться по другим причинам, чем пользовательский интерфейс. Варианты использования не зависят от пользовательского интерфейса. Это также упростит их тестирование и повторное использование с другими пользовательскими интерфейсами.
Consider a controller class having set of functions that accepts T and returns R after executing some logic
Имейте в виду, что типы параметров и возвращаемых значений контроллеров не совпадают с типами вариантов использования.
Ваш контроллер может использовать типы, предназначенные для сериализации и десериализации json. Это вопрос транспорта. Варианты использования не заботятся о транспорте. Способ передачи данных — это деталь. Сеть — это деталь. Если вы используете одни и те же типы для контроллеров и вариантов использования, вы создадите зависимость между ними.
Чистая архитектура - это тот, который имеет меньшую связь между его слоями. Теперь, когда мы пытаемся применить чистую архитектуру к веб-приложению, такому как Google Фото, оно может иметь несколько слоев, например:
- Слой пользовательского интерфейса (тот, который воспринимается пользователем)
- Уровень маршрутизации, который может направить URL-адрес в нужный файл класса.
- В зависимости от вариантов использования может быть несколько слоев адаптера.
Уровень сохраняемости, который снова можно разделить на подкатегории,
4.1. Сохранение метаданных (например, Postgress, MySQL)
4.2. Постоянство содержимого (например, Hadoop)
Как здесь представлены варианты использования?
Вариант использования описывает взаимодействие пользователя с системой. Это может быть так же просто, как проверка неправильного пароля во время аутентификации (или) предоставление опций для применения фильтра к изображению. Реализация варианта использования может закончиться методом или может возникнуть между несколькими классами и файлами.
Чистая архитектура — это своего рода руководство, которое настаивает на том, чтобы у нас была слабая связь между слоями, чтобы замена одного слоя другим была легкой с минимальными изменениями.