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