Comments 5
От временной связности не всегда можно избавиться. Временная связность API часто диктуется самой природой используемых абстракций над чем-либо. Многие процессы просто должны выполняться последовательно во времени. Ну вот, например, возьмём некую сущность, которая должна быть сначала создана, затем подготовлена, затем выполнена, а затем мы можем спросить у неё о результатах выполнения. Получается такой API:
1. Create (Создать)
2. Prepare (Подготовить состояние)
3. Run (Выполнить работу)
4. GetResult (Получить результаты)
Как в этом случае избавиться от временной связности? Нельзя получить результаты, не выполнив работы. Можно резонно заметить, что можно запихать все эти 4 действия в одно, на что я отвечу, что это сделает API негибким и перегруженным, сломает логику и модульность, т. к. данная сущность может быть подготовлена один раз, а работу выполнить несколько раз над разными объектами. К тому же подготовка состоянием по умолчанию может занимать длительное время, а требуется не всегда, а также не всегда требуются результаты работы. В общем, всё не так хорошо как часто рассуждают "Астронавты от Архитектуры".
1. Create (Создать)
2. Prepare (Подготовить состояние)
3. Run (Выполнить работу)
4. GetResult (Получить результаты)
Как в этом случае избавиться от временной связности? Нельзя получить результаты, не выполнив работы. Можно резонно заметить, что можно запихать все эти 4 действия в одно, на что я отвечу, что это сделает API негибким и перегруженным, сломает логику и модульность, т. к. данная сущность может быть подготовлена один раз, а работу выполнить несколько раз над разными объектами. К тому же подготовка состоянием по умолчанию может занимать длительное время, а требуется не всегда, а также не всегда требуются результаты работы. В общем, всё не так хорошо как часто рассуждают "Астронавты от Архитектуры".
Такой код можно свести к следующему, на каждом шаге задействовав свой тип (интерфейс):
Кодить интерфейсы сложно и муторно, зато пользоваться безопасно
factory = MyClass.Create();
worker = factory.Prepare(1,2,3);
task = worker.Run();
result = task.GetResult();Кодить интерфейсы сложно и муторно, зато пользоваться безопасно
Да, избавились от временной связности, получили три сущности вместо одной. Возможно, это и хорошо, но такой код уже пахнет перепроектированием, хотя и является безопасным с точки зрения использования API. Я думаю, что в данном вопросе нужно опираться на здравый смысл, нежели слепо следовать апологетам истинной инкапсуляции.
Вообще, я не могу припомнить случаев, когда бы я испытывал серьезные проблемы из-за временной связности, потому что она встречается в интерфейсах многих библиотек, многие из которых сложно назвать плохо спроектированными.
Вообще, я не могу припомнить случаев, когда бы я испытывал серьезные проблемы из-за временной связности, потому что она встречается в интерфейсах многих библиотек, многие из которых сложно назвать плохо спроектированными.
Как вариант — использовать флаги вызван/не вызван с подробным описанием ошибки и, прямо в ней, примером правильной последовательности вызовов.
В идеале, ошибочный код не должен ждать, пока его запустят, он не должен компилироваться.
Если разработчик написал несколько раз неправильно, и на некоторой ветке исполнения код дал ему по рукам, то нет гарантии (кроме тестирования со 100% покрытием), что остальные участки кода будут корректно исправлены.
Если разработчик написал несколько раз неправильно, и на некоторой ветке исполнения код дал ему по рукам, то нет гарантии (кроме тестирования со 100% покрытием), что остальные участки кода будут корректно исправлены.
Sign up to leave a comment.
«Запах» проектирования: временная связность