Комментарии 18
Интересно. Я в этом деле "чайник", но даже мне было понятно. Спасибо!
Привет! Хорошая статья, особенно спасибо за ссылки на полезные материалы.
По поводу предложений, есть одно интересное.
Если я правильно понял, ваше решение позволяет абстрагировать модель данных и транспортный слой от сервисной части кода (там, где выполняется логика).
Пройдя путь проектирования и реализации нескольких платформ разработки, я могу сказать, что ваше решение можно удачно применить для решения основной задачи таких платформ: "Как комбинировать разработку, отладку, прототипирование и развертывание без неудобств и накладных расходов в рамках многих команд и большого количества (>100) модулей ?"
Да, обе эти задачи решаются с помощью данной механики. Разделение слоев мы уже решили через единую точку входа и выхода из бизнес логики. А чтобы добавить вторую, нужны дополнительные организационные и технологические ухищрения: возможность конфигурации secondary adapter'ов (из терминологии гексогональной архитектуры) и отсутствие прямых вызов из сервиса в сервис или сервиса в домен
IMHO, такие штуки добавляют слишком много неявной магии в поведение программы.
Прям представляю разработчика, который читает код и не понимает, почему выполняется что-то левое, а не то, что он написал.
Согласился бы с этим утверждением, если бы речь шла об AspectJ именно этот его недостаток привел меня к идее реализовать подобную механику. Однако здесь вызов основного метода и всех вспомогательных ищется точно также, как если бы он вызывался напрямую за счет ссылок на методы. В конечном итоге сложность не выше, чем если бы все эти методы вызывались бы просто последовательно из другого метода. А преимущество заключается в том, что сам MethodExecutor является объектом и к нему можно применить порождающие паттерны проектирования, сократив дубликацию кода.
Больше похоже на билдер для цепочки вызовов, предложу альтернативные названия класса MethodExecutionBuilder или ExecutionPipeline
Он так назван, потому что вызов всей цепочки собранной тоже в нем. Возможно есть смысл разделить сборку и исполнение, ну и названия соотвествующие сделать. Спасибо за предложение.
Либо я чего-то не понял, либо вы какой-то pipeline-фреймворк навелосипедили. Так и не понял при чем здесь AspectJ был, если его суть в изменении поведения программы без изменения кода в тех местах, где это изменение нужно. У вас же это изменения явно и в тех местах где оно необходимо.
Вы все верно поняли. Это тот самый «вирус из Индии», который просит себя распаковать и запустить.
Либо я чего-то не понял, либо вы какой-то pipeline-фреймворк навелосипедили.
Да, вообще-то я ничего и не велосипедил. Целью статьи было показать как с помощью ссылок на методы можно повысить гибкость в программе на примере одной простой штуки, которую я собрал, не претендуя на какое-либо новаторство. Я вообще считаю, что ссылки на методы незаслуженно мало используются при проектирование кода. А в заключение заметил, что с помощью даже такой простой штуки можно много каких вещей наворотить вокруг.
Так и не понял при чем здесь AspectJ был
Он был в списке инструментов, которые я посмотрел, и отметил что он может и почему он мне не подходит не более того, а также подчеркнул, что несмотря на это существуют ситуации где его использование оправдано.
Выбросить все, что вы написали. Но это значит, бизнес останется без новых доработок на квартал так точно. Не уверен, что кто-то выбирал этот путь в реальности, но в теории он существует
Твиттер?
Мне не хватило понимания: […]
И, поскольку вас забанили в редакторе кода и отобрали последний, доставшийся вам от деда, деревянный JDK, вы забили на решение, которое более 25 закалялось в боях, и просто написали враппер вокруг (дайте подумать) — прямого вызова функции!
Твиттер?
Про Твиттер не знаю, если поделитесь источником, где указано, что именно так и поступили его создатели буду благодарен, хороший аргумент для споров с начальством по этому поводу.
И, поскольку вас забанили в редакторе кода и отобрали последний, доставшийся вам от деда, деревянный JDK, вы забили на решение, которое более 25 закалялось в боях
Подозреваю, что вы некорректно поняли мою причину отказа от AspectJ, посчитав, что я отказался от него из-за того, что не достиг полного понимания его работы в статьях и поленился исследовать его другими способами. Но фраза "Мне не хватило понимания:" относилась к моей оценке статей, на которые я ссылаюсь, а не к моему пониманию того, как работает AspectJ. Я провел исследование статей об AspectJ в интернете и обнаружил, что собранные мной материалы, не дают полного представления о том, как он работает, и заявил об этом в статье. Моя статья не про AspectJ, поэтому я не занимаюсь в ней его детальным описанием.
просто написали враппер вокруг (дайте подумать) — прямого вызова функции!
Так точно, именно это я и сделал! Потому что враппер вокруг прямого вызова функций с помощью небольшой магии позволяет мне сделать много интересных вещей - например написать простые обработчики ошибок, чтобы убрать по всему коду try-catch, чтобы снизить когнитивную сложность кода. Или добавить не функциональных требований к вызовам функций, не изменяя их кода, написанного не мной, с минимальным риском попортить функциональные требования для которых писалась эта функция. В статье приведен пример простейшего использования этого чудесного, на мой взгляд, механизма, который не заслужил достойного к себе внимания.
https://search.brave.com/search?q=twitter+ruby+to+scala
вы некорректно поняли мою причину отказа от AspectJ, посчитав, что я отказался от него из-за того, что не достиг полного понимания его работы в статьях и поленился исследовать его другими способами […]
Я провел исследование статей об AspectJ в интернете и обнаружил, что собранные мной материалы, не дают полного представления о том, как он работает, и заявил об этом в статье.
А как понять корректно? Спрашиваю для друга.
враппер вокруг прямого вызова функций с помощью небольшой магии позволяет мне сделать много интересных вещей
Люди придумали такие слова, как «plugin», «middleware», «callback» — задолго до появления AspectJ. Я даже недавно рассказывал, как этого добиваются в акторной модели. Для этого, уверен, есть и общеизвестные паттерны ООП (я их не заучивал, поэтому это — не более, чем догадка).
В тексте выше есть абсолютно прекрасная фраза:
тесты, это не только проверка корректности работы части программы, но и первое место откуда будет вызываться код и именно в тесте можно узнать, удобно ли им будет пользоваться
Под этим я готов подписаться на сто процентов, более того, я сам ровно это заявляю на каждом углу. Мой тест выглядел бы примерно вот так:
@Test
void howItWorkTest(){
CallWrapper cw = new CallWrapper(StringBuilder, [OtherWrapper, …, this]);
System.out.println(cw.execute(…));
}А this (OtherWrapper и все остальные) должен был бы имплементировать интерфейс MethodCallWrapper или типа того.
но вы же просто заменили catch на addWrapper(ExceptionHandler.DEFAULT)
это не снизило когнитивную нагрузку при чтении
это ее повысило
вместо привычного, описанного во всех учебниках синтаксиса, надо осознавать ваш доморощенный
кстати, покажите пожалуйста пример с вашим аналогом finally (post-processor, который отрабатывает всегда, вне зависимости от того, было ли выброшено исключение в процессе прохода по вашему пайплайну)
Ну то есть основная ваша идея в том, что если есть технология, что уже довольно долго развивается и популярна, то любые размышления по теме — это повод очень неумно (но с вашей точки зрения, видимо, очень остроумно), попытаться указать автору на недостаток знаний, прицепившись к одной фразе, но не высказав никакой критики по существу?.
«Я не осилил понять, как работает AspectJ, и потому написал свою медленную (бенчмарки где?), неуклюжую реализацию Dependency Injection на врапперах» — это не размышления.
Размышления — это: «вот пример, в котором я замерил производительность и удобство, они меня не устроили, поэтому я изучил существующие решения (см. мои следующие комментарии), которые тоже не подошли, и реализовал своё, вот бенчмарки, вот рабочий код, вот в чем оно лучше».
Как я добился гибкости в приложении и при чем тут ссылки на методы?