Комментарии 18
Интересно. Я в этом деле "чайник", но даже мне было понятно. Спасибо!
Привет! Хорошая статья, особенно спасибо за ссылки на полезные материалы.
По поводу предложений, есть одно интересное.
Если я правильно понял, ваше решение позволяет абстрагировать модель данных и транспортный слой от сервисной части кода (там, где выполняется логика).
Пройдя путь проектирования и реализации нескольких платформ разработки, я могу сказать, что ваше решение можно удачно применить для решения основной задачи таких платформ: "Как комбинировать разработку, отладку, прототипирование и развертывание без неудобств и накладных расходов в рамках многих команд и большого количества (>100) модулей ?"
Да, обе эти задачи решаются с помощью данной механики. Разделение слоев мы уже решили через единую точку входа и выхода из бизнес логики. А чтобы добавить вторую, нужны дополнительные организационные и технологические ухищрения: возможность конфигурации secondary adapter'ов (из терминологии гексогональной архитектуры) и отсутствие прямых вызов из сервиса в сервис или сервиса в домен
IMHO, такие штуки добавляют слишком много неявной магии в поведение программы.
Прям представляю разработчика, который читает код и не понимает, почему выполняется что-то левое, а не то, что он написал.
Согласился бы с этим утверждением, если бы речь шла об AspectJ именно этот его недостаток привел меня к идее реализовать подобную механику. Однако здесь вызов основного метода и всех вспомогательных ищется точно также, как если бы он вызывался напрямую за счет ссылок на методы. В конечном итоге сложность не выше, чем если бы все эти методы вызывались бы просто последовательно из другого метода. А преимущество заключается в том, что сам MethodExecutor является объектом и к нему можно применить порождающие паттерны проектирования, сократив дубликацию кода.
Больше похоже на билдер для цепочки вызовов, предложу альтернативные названия класса MethodExecutionBuilder или ExecutionPipeline
Он так назван, потому что вызов всей цепочки собранной тоже в нем. Возможно есть смысл разделить сборку и исполнение, ну и названия соотвествующие сделать. Спасибо за предложение.
Либо я чего-то не понял, либо вы какой-то pipeline-фреймворк навелосипедили. Так и не понял при чем здесь AspectJ был, если его суть в изменении поведения программы без изменения кода в тех местах, где это изменение нужно. У вас же это изменения явно и в тех местах где оно необходимо.
Либо я чего-то не понял, либо вы какой-то pipeline-фреймворк навелосипедили.
Да, вообще-то я ничего и не велосипедил. Целью статьи было показать как с помощью ссылок на методы можно повысить гибкость в программе на примере одной простой штуки, которую я собрал, не претендуя на какое-либо новаторство. Я вообще считаю, что ссылки на методы незаслуженно мало используются при проектирование кода. А в заключение заметил, что с помощью даже такой простой штуки можно много каких вещей наворотить вокруг.
Так и не понял при чем здесь AspectJ был
Он был в списке инструментов, которые я посмотрел, и отметил что он может и почему он мне не подходит не более того, а также подчеркнул, что несмотря на это существуют ситуации где его использование оправдано.
Твиттер?
Про Твиттер не знаю, если поделитесь источником, где указано, что именно так и поступили его создатели буду благодарен, хороший аргумент для споров с начальством по этому поводу.
И, поскольку вас забанили в редакторе кода и отобрали последний, доставшийся вам от деда, деревянный JDK, вы забили на решение, которое более 25 закалялось в боях
Подозреваю, что вы некорректно поняли мою причину отказа от AspectJ, посчитав, что я отказался от него из-за того, что не достиг полного понимания его работы в статьях и поленился исследовать его другими способами. Но фраза "Мне не хватило понимания:" относилась к моей оценке статей, на которые я ссылаюсь, а не к моему пониманию того, как работает AspectJ. Я провел исследование статей об AspectJ в интернете и обнаружил, что собранные мной материалы, не дают полного представления о том, как он работает, и заявил об этом в статье. Моя статья не про AspectJ, поэтому я не занимаюсь в ней его детальным описанием.
просто написали враппер вокруг (дайте подумать) — прямого вызова функции!
Так точно, именно это я и сделал! Потому что враппер вокруг прямого вызова функций с помощью небольшой магии позволяет мне сделать много интересных вещей - например написать простые обработчики ошибок, чтобы убрать по всему коду try-catch, чтобы снизить когнитивную сложность кода. Или добавить не функциональных требований к вызовам функций, не изменяя их кода, написанного не мной, с минимальным риском попортить функциональные требования для которых писалась эта функция. В статье приведен пример простейшего использования этого чудесного, на мой взгляд, механизма, который не заслужил достойного к себе внимания.
но вы же просто заменили catch на addWrapper(ExceptionHandler.DEFAULT)
это не снизило когнитивную нагрузку при чтении
это ее повысило
вместо привычного, описанного во всех учебниках синтаксиса, надо осознавать ваш доморощенный
кстати, покажите пожалуйста пример с вашим аналогом finally (post-processor, который отрабатывает всегда, вне зависимости от того, было ли выброшено исключение в процессе прохода по вашему пайплайну)
Ну то есть основная ваша идея в том, что если есть технология, что уже довольно долго развивается и популярна, то любые размышления по теме — это повод очень неумно (но с вашей точки зрения, видимо, очень остроумно), попытаться указать автору на недостаток знаний, прицепившись к одной фразе, но не высказав никакой критики по существу?.
Как я добился гибкости в приложении и при чем тут ссылки на методы?