Прикол в том, чтобы не пересобирать модули, которые зависят только от api фичи. Ведь в случае изменения impl, api пересобираться не будет, а значит и модули, которые от него зависят.
А вообще есть ещё подход, когда фичу на три модуля разбивают:
api – только публичный интерфейс
impl – реализация
factory – то от чего зависят модули, которым нужна фича, предоставляет реализацию, через публичные интерфейсы
Смысл такого подхода в том, что если меняем impl, то пересобирается только impl и factory, а пересборка зависящих модулей не происходит, т.к. factory по сути не изменился
Удобно, ответить только на те тезисы, на которые есть, что ответить (по мнению автора) и проигнорировать ответы на остальное (с примерами как и просили).
В реальной жизни не используют статические и экземплярые конструкторы, и наследование? Используют и еще как, и полно другого г**на
Никто не говорил, что это не используется, вы видимо не смогли понять смысла написанного. Никто не использует это в таком виде. А то что написано куча плохого кода никто и не спорит, вот только это не зависит от используемого инструмента, только от человека, который его использовал
То есть единственный способ нормально написать код это использовать функцию, то есть ФП?
Ну а кто мне запретит использовать ФП и ООП вместе по мере необходимости?) И это не доказывает никакого превосходства. Просто для одного хорошо использовать один подход, а для другого – другой. И помимо Java и C# есть и другие языки в которых это вполне возможно.
А по поводу примера. Можно и не отдельной функцией. Можно было сделать общий интерфейс с функцией getDisplayName(), а в классах где это необходимо добавить его реализацию. Мне вот не хотелось бы чтобы этот метод использовал тип данных для которого это не предназначено во избежание дальнейших ошибок, особенно при расширении и изменении функциональности. Ну а переиспользование это конечно хорошо, но не когда ради него приходится писать огромную функцию переберающиую все возможные случаи переданных данных. Может у меня для разных данных должна быть разная логика их обработки, для каждых плодить отдельную функцию, которая к тому же проверяет что ей передали менно те данные с которыми она должна работать? И где тогда удобство переиспользования и почему это лучше вызова метода класса?
Блокирующая синхронизация, привет фризы из главного потока, рейс кондишены и дедлоки.
Чтобы не фризить главный поток, не надо пихать тяжёлые операции в главный поток ещё и под синхронизацией. В чём проблема обработать в отдельном потоке, а синхронизировать только ради передачи результата? И это при том, что есть и другие способы. Например, в той же Java, есть volatile и потокобезопасные типы данных, которые прекрасно могут работать без излишней синхронизации. Проблема рейс кондишена и дедлока вообще скорее относится к проблемам архитектурным. То есть это не из-за того, что кто-то использовал синхронизацию, а из-за того, что неправильно её использовал.
Вот здесь в целом написано про персборки как раз с примером подобной разбивки: https://habr.com/ru/companies/yandex/articles/419295/
Прикол в том, чтобы не пересобирать модули, которые зависят только от api фичи. Ведь в случае изменения impl, api пересобираться не будет, а значит и модули, которые от него зависят.
А вообще есть ещё подход, когда фичу на три модуля разбивают:
api – только публичный интерфейс
impl – реализация
factory – то от чего зависят модули, которым нужна фича, предоставляет реализацию, через публичные интерфейсы
Смысл такого подхода в том, что если меняем impl, то пересобирается только impl и factory, а пересборка зависящих модулей не происходит, т.к. factory по сути не изменился
Удобно, ответить только на те тезисы, на которые есть, что ответить (по мнению автора) и проигнорировать ответы на остальное (с примерами как и просили).
Никто не говорил, что это не используется, вы видимо не смогли понять смысла написанного. Никто не использует это в таком виде. А то что написано куча плохого кода никто и не спорит, вот только это не зависит от используемого инструмента, только от человека, который его использовал
Ну а кто мне запретит использовать ФП и ООП вместе по мере необходимости?) И это не доказывает никакого превосходства. Просто для одного хорошо использовать один подход, а для другого – другой. И помимо Java и C# есть и другие языки в которых это вполне возможно.
А по поводу примера. Можно и не отдельной функцией. Можно было сделать общий интерфейс с функцией getDisplayName(), а в классах где это необходимо добавить его реализацию. Мне вот не хотелось бы чтобы этот метод использовал тип данных для которого это не предназначено во избежание дальнейших ошибок, особенно при расширении и изменении функциональности. Ну а переиспользование это конечно хорошо, но не когда ради него приходится писать огромную функцию переберающиую все возможные случаи переданных данных. Может у меня для разных данных должна быть разная логика их обработки, для каждых плодить отдельную функцию, которая к тому же проверяет что ей передали менно те данные с которыми она должна работать? И где тогда удобство переиспользования и почему это лучше вызова метода класса?
Чтобы не фризить главный поток, не надо пихать тяжёлые операции в главный поток ещё и под синхронизацией. В чём проблема обработать в отдельном потоке, а синхронизировать только ради передачи результата? И это при том, что есть и другие способы. Например, в той же Java, есть volatile и потокобезопасные типы данных, которые прекрасно могут работать без излишней синхронизации. Проблема рейс кондишена и дедлока вообще скорее относится к проблемам архитектурным. То есть это не из-за того, что кто-то использовал синхронизацию, а из-за того, что неправильно её использовал.