С первым вопросом, судя по комментариям, мы разобрались и уже выяснялось что от ООП можно и не избавляться. Ок.
Отвечаю на второй вопрос. ООП полезен тем, что можно оперировать объектами. У объекта может быть множество полей и они не "висят в воздухе" как глобальные переменные, а принадлежат конкретному объекту. И это легко маппится на реальность. Есть человек у него есть Имя Фамилия Отчество (в некоторых странах), дата рождения и др. У человека есть адрес фактического проживания (у большинства), который состоит из страны, населенного пункта, улицы, дома и др. У человека есть документ удостоверяющий личность. У документа есть номер и дата выдачи и др. И еще много-много других параметров. А ещё автомобиль и другое имущество. И все это важно в контексте оформления и учёта договоров страхования. Как оперировать этими параметрами и описывать бизнес логику в коде также интуитивно понятно как в ООП?
Касательно вашего последнего вопроса по сверке. Я не знаком с этой предметной областью и не знаю всех параметров, по которым нужно сверять счета. Но если там 1 или 2 параметра, то это частный случай. Конечно, чтобы написать, например, Калькулятор, то ООП тоже не обязателен. Но возвращаясь к тому с чего начинали: почему не использовать поход, который обладает большей мощью и позволяет решать и простые, и сложные задачи
Погодите. Вы вначале предложили избавиться от ООП. Я спросил что в замен. Вы предложили шаблон проектирования, который можно использовать и в ООП и в процедурном программировании (может и в функциональном). Когда я указал что это разные уровни и одно другому не мешает, вы согласились, что конечно не мешает. Зачем тогда избавляться от ООП, если он не мешает? :)
А помогает так, что легко формализовать реальный процесс. Каждый этап выполнения команды - это отдельный класс. А логика отдельного этапа описана в методе этого класса. А управление всей последовательностью этапов - это тоже отдельный класс. А действие запуска последовательности находится в методе. Все как и написано в вашем примере. Красота!
Если мы говорим в общем, то нужно учесть и случай с крупными компаниями, где множество систем, интеграций и давно устоявшиеся процессы. И тогда, чтобы разбить юзер стори на мелкие задачи нужен не только разработчик, а ещё аналитик и/или архитектор. А ещё, не редко, нужны и разработчики из других систем. Потому что стори "Я как пользователь хочу оплатить заказ пластиковой картой" выливается в то, что в системе разработчик должен вывести на экране кнопку, которая будет вызывать систему, отвечающую за формирование заказов в эквайрингах. Но эту кнопку нельзя выводить всем, а нужно проверить, что юзер не находится в черном списке. А чтобы вызвать систему с черными списками, нужно сынтегрироваться с ней. А в их доке написано, хост такой-то, порт такой-то. И только архитектор или разработчики той системы знают что она использует аутентификацию через KeyCloak. А чтобы целевая система могла обращаться к KeyCloak и к системе с черными списками, нужно заказать сетевые доступа. Также чтобы и система по формированию заказов могла вызывать новый эквайринг нужны сетевые доступа. Но ещё есть финансовая система учёта. И система по формированию заказов должна сынтегрироваться и с ней, чтобы правильно отправлять в нее инф по заказам в новом эквайринге. Но разработчики не знают какие данные нужны для учёта. Нужно это узнать у аналитика финансовой системы или бухгалтеров. И т.д.
Поэтому нужно по нескольку раз обойти архитектора, аналитиков, разработчиков и продукт овнеров, а потом полученную оценку умножить на 1,5
Про Простейшую парадигму ничего не слышал :) Знаю Процедурную, Объектно ориентированную и Функциональную. И как верно заметил Робер Мартин каждая из них нас по-своему ограничивает. То что вы привели в примере кода, это паттерн Command (Команда или Действие), но ваш собственный пример использует Объектно Ориентированное Программирование (interface, class, new OperationId()).
Наверное функциональщики приведут много примеров под этим комментом. Но я и коллеги из "экспертной группы" абсолютно уверены, что для описания бизнес логики в энтерпрайз системах лучше ООП пока ничего не придумали. Реальная жизнь легко маппится на классы, поля классов и методы и любой бизнес процесс можно формализовать с любой точностью.
Давайте уточним. Не очень понятен или не очень правилен?) Попробую ответить на оба мнения.
1) Во вспомогательном классе мы инжектим ApplicationContext в статическое поле класса. И через статический метод предоставляем доступ к его методу getBean(). Таким образом из любого места кода (который выполняется в рантайме и после загрузки Spring контекста) мы можем получить любой Spring бин и работать с его методами. В итоге при рефакторинге вы и делаете самописный синглтон спринговым бином, но во всех местах где он уже используется вы просто заменяете MySingleton.getInstance() на Context.getBean(MySingleton.class)
2) Безусловно это не best practice. Но тут нужно понимать ограничения. А ограничения тут такие - если вы спринговым бинам с одинаковыми классами дадите разные имена, надеясь что их потом можно подцепить через Qualifier, то вас будет ждать разочарование. А если один класс - один бин, то ничего страшного. Но! Конечно этот подход был временной мерой, постепенно, когда все больше и больше классов переводились на спринг бины мы уже уходили и от этого "интересного решения" на стандартный спринговый подход.
Что мешало в рамках конкретной бизнес-задачи переводить затрагиваемые синглтоны в бины?
Объем изменений) Представляете продакшн код? Местами иерархия вызовов более 10ка классов. А в большинстве классов ещё и присутствует композиция. И одно цепляется за другое и в итоге нужно переписать тонну кода. Да, это можно было бы сделать один раз и потом всем жить нормальной жизнью. Но бизнес бы не понял, если бы мы попросили стопорнуть всю разработку на неделю, пока разработчики перелопатят все синглтоны, а потом ещё все проверят и где-то ещё что-то забудут. А разработку бы пришлось стопорнуть, иначе бы рефакторщики потом утонули в мерж конфликтах. Как раз мы и искали подход, чтобы все можно было делать постепенно
Вы про теорию или практику? Русский язык весьма богат и одно и то же можно называть разными словами. Как я понял вашу идею, Spring делает то о чем вы говорите, про другие IoC container фреймворки сказать не могу. А если вы говорите о другом, тогда встречный вопрос: "Является ли это мейнстримом в Java стэке?". Если порассуждать шире, почему в enterprise практически не пользуются вчера изобретенными или не прижившимися технологиями. Потому что у мейнстрим технологий понятны плюсы и минусы, найдены обходные пути, на рынке много людей, которые знакомы с ней. Поэтому если кому-то в голову пришла какая-то идея - отлично, возможно она перевернет индустрию, внедрите ее сначала в стартап, когда она там обкатается, тогда enterprise начнет к ней присматриваться
Здесь все-таки указана наша идеология в конкретном контексте. Чуть добавлю деталей: продукт - это система, к которой подключаются компании и через него осуществляют продажи полисов; продукт (система) прибыльный и востребованный; команда состоит из владельца продукта и разработчиков; работа идёт короткими циклами.
Невостребованные на рынке продукты в Компании не живут годами, если владелец продукта выдвинул неверную гипотезу, то в скором времени он это поймет по метрикам и отложит эту идею и пойдет придумывать новую фичу.
А что входит в работу разработчика, которую он делает хорошо? На таких продуктах мы приветствуем, когда разработчик смотрит шире чем классы, методы и конфиги. Когда проектируешь структуру в бд, можно пристальнее посмотреть на данные и на их связи и даже задав вопрос продукт оунеру, можно посеять какую-то полезную идею в его голове. Опять же генерить идеи в одиночку, не так эффективно как командой. Но ещё раз, это не обязанность разработчиков, но очень большое преимущество. Если разработчику (да, пожалуй, и другим ролям) все равно на результат его труда, это нездоровая история.
А про процент от прибыли, ну некоторая корреляция есть, да. В компании есть ежеквартальное премирование и если владелец продукта и стэкхолдеры и коллеги видят что в этом квартале хорошие показатели и кто-то отличился, то у него есть все шансы получить больше денег.
С первым вопросом, судя по комментариям, мы разобрались и уже выяснялось что от ООП можно и не избавляться. Ок.
Отвечаю на второй вопрос. ООП полезен тем, что можно оперировать объектами. У объекта может быть множество полей и они не "висят в воздухе" как глобальные переменные, а принадлежат конкретному объекту. И это легко маппится на реальность. Есть человек у него есть Имя Фамилия Отчество (в некоторых странах), дата рождения и др. У человека есть адрес фактического проживания (у большинства), который состоит из страны, населенного пункта, улицы, дома и др. У человека есть документ удостоверяющий личность. У документа есть номер и дата выдачи и др. И еще много-много других параметров. А ещё автомобиль и другое имущество. И все это важно в контексте оформления и учёта договоров страхования. Как оперировать этими параметрами и описывать бизнес логику в коде также интуитивно понятно как в ООП?
Касательно вашего последнего вопроса по сверке. Я не знаком с этой предметной областью и не знаю всех параметров, по которым нужно сверять счета. Но если там 1 или 2 параметра, то это частный случай. Конечно, чтобы написать, например, Калькулятор, то ООП тоже не обязателен. Но возвращаясь к тому с чего начинали: почему не использовать поход, который обладает большей мощью и позволяет решать и простые, и сложные задачи
Погодите. Вы вначале предложили избавиться от ООП. Я спросил что в замен. Вы предложили шаблон проектирования, который можно использовать и в ООП и в процедурном программировании (может и в функциональном). Когда я указал что это разные уровни и одно другому не мешает, вы согласились, что конечно не мешает. Зачем тогда избавляться от ООП, если он не мешает? :)
А помогает так, что легко формализовать реальный процесс. Каждый этап выполнения команды - это отдельный класс. А логика отдельного этапа описана в методе этого класса. А управление всей последовательностью этапов - это тоже отдельный класс. А действие запуска последовательности находится в методе. Все как и написано в вашем примере. Красота!
...
Можно и на JS. Про первую часть ок, допустим что это из-за реализации Java.
Но ООП никак не мешает использованию этого паттерна (или как вы называете парадигмы), а даже помогает.
Если мы говорим в общем, то нужно учесть и случай с крупными компаниями, где множество систем, интеграций и давно устоявшиеся процессы. И тогда, чтобы разбить юзер стори на мелкие задачи нужен не только разработчик, а ещё аналитик и/или архитектор. А ещё, не редко, нужны и разработчики из других систем. Потому что стори "Я как пользователь хочу оплатить заказ пластиковой картой" выливается в то, что в системе разработчик должен вывести на экране кнопку, которая будет вызывать систему, отвечающую за формирование заказов в эквайрингах. Но эту кнопку нельзя выводить всем, а нужно проверить, что юзер не находится в черном списке. А чтобы вызвать систему с черными списками, нужно сынтегрироваться с ней. А в их доке написано, хост такой-то, порт такой-то. И только архитектор или разработчики той системы знают что она использует аутентификацию через KeyCloak. А чтобы целевая система могла обращаться к KeyCloak и к системе с черными списками, нужно заказать сетевые доступа. Также чтобы и система по формированию заказов могла вызывать новый эквайринг нужны сетевые доступа. Но ещё есть финансовая система учёта. И система по формированию заказов должна сынтегрироваться и с ней, чтобы правильно отправлять в нее инф по заказам в новом эквайринге. Но разработчики не знают какие данные нужны для учёта. Нужно это узнать у аналитика финансовой системы или бухгалтеров. И т.д.
Поэтому нужно по нескольку раз обойти архитектора, аналитиков, разработчиков и продукт овнеров, а потом полученную оценку умножить на 1,5
Про Простейшую парадигму ничего не слышал :) Знаю Процедурную, Объектно ориентированную и Функциональную. И как верно заметил Робер Мартин каждая из них нас по-своему ограничивает. То что вы привели в примере кода, это паттерн Command (Команда или Действие), но ваш собственный пример использует Объектно Ориентированное Программирование (interface, class, new OperationId()).
Наверное функциональщики приведут много примеров под этим комментом. Но я и коллеги из "экспертной группы" абсолютно уверены, что для описания бизнес логики в энтерпрайз системах лучше ООП пока ничего не придумали. Реальная жизнь легко маппится на классы, поля классов и методы и любой бизнес процесс можно формализовать с любой точностью.
Спасибо за совет. А какую парадигму предлагаете?
Давайте уточним. Не очень понятен или не очень правилен?) Попробую ответить на оба мнения.
1) Во вспомогательном классе мы инжектим ApplicationContext в статическое поле класса. И через статический метод предоставляем доступ к его методу getBean(). Таким образом из любого места кода (который выполняется в рантайме и после загрузки Spring контекста) мы можем получить любой Spring бин и работать с его методами. В итоге при рефакторинге вы и делаете самописный синглтон спринговым бином, но во всех местах где он уже используется вы просто заменяете
MySingleton.getInstance()наContext.getBean(MySingleton.class)2) Безусловно это не best practice. Но тут нужно понимать ограничения. А ограничения тут такие - если вы спринговым бинам с одинаковыми классами дадите разные имена, надеясь что их потом можно подцепить через Qualifier, то вас будет ждать разочарование. А если один класс - один бин, то ничего страшного. Но! Конечно этот подход был временной мерой, постепенно, когда все больше и больше классов переводились на спринг бины мы уже уходили и от этого "интересного решения" на стандартный спринговый подход.
Объем изменений) Представляете продакшн код? Местами иерархия вызовов более 10ка классов. А в большинстве классов ещё и присутствует композиция. И одно цепляется за другое и в итоге нужно переписать тонну кода. Да, это можно было бы сделать один раз и потом всем жить нормальной жизнью. Но бизнес бы не понял, если бы мы попросили стопорнуть всю разработку на неделю, пока разработчики перелопатят все синглтоны, а потом ещё все проверят и где-то ещё что-то забудут. А разработку бы пришлось стопорнуть, иначе бы рефакторщики потом утонули в мерж конфликтах. Как раз мы и искали подход, чтобы все можно было делать постепенно
Вы про теорию или практику? Русский язык весьма богат и одно и то же можно называть разными словами. Как я понял вашу идею, Spring делает то о чем вы говорите, про другие IoC container фреймворки сказать не могу. А если вы говорите о другом, тогда встречный вопрос: "Является ли это мейнстримом в Java стэке?". Если порассуждать шире, почему в enterprise практически не пользуются вчера изобретенными или не прижившимися технологиями. Потому что у мейнстрим технологий понятны плюсы и минусы, найдены обходные пути, на рынке много людей, которые знакомы с ней. Поэтому если кому-то в голову пришла какая-то идея - отлично, возможно она перевернет индустрию, внедрите ее сначала в стартап, когда она там обкатается, тогда enterprise начнет к ней присматриваться
Не уловил идею. Как инициализировать зависимость из контекста?
Здесь все-таки указана наша идеология в конкретном контексте. Чуть добавлю деталей: продукт - это система, к которой подключаются компании и через него осуществляют продажи полисов; продукт (система) прибыльный и востребованный; команда состоит из владельца продукта и разработчиков; работа идёт короткими циклами.
Невостребованные на рынке продукты в Компании не живут годами, если владелец продукта выдвинул неверную гипотезу, то в скором времени он это поймет по метрикам и отложит эту идею и пойдет придумывать новую фичу.
А что входит в работу разработчика, которую он делает хорошо? На таких продуктах мы приветствуем, когда разработчик смотрит шире чем классы, методы и конфиги. Когда проектируешь структуру в бд, можно пристальнее посмотреть на данные и на их связи и даже задав вопрос продукт оунеру, можно посеять какую-то полезную идею в его голове. Опять же генерить идеи в одиночку, не так эффективно как командой. Но ещё раз, это не обязанность разработчиков, но очень большое преимущество. Если разработчику (да, пожалуй, и другим ролям) все равно на результат его труда, это нездоровая история.
А про процент от прибыли, ну некоторая корреляция есть, да. В компании есть ежеквартальное премирование и если владелец продукта и стэкхолдеры и коллеги видят что в этом квартале хорошие показатели и кто-то отличился, то у него есть все шансы получить больше денег.