В теории можно сделать идеальный проект с двадцаткой бандлов всех мастей которые делают «мало, но хорошо»
еще раз — не надо делить проект на бандлы. Бандлы для реюза кода между проектами, инфраструктура какая-то, обобщенный функционал. Например вам надо быстро прикрутить websockets — ставим centrifugo bundle. Бизнес логики в бандлах быть не должно.
Я считаю что нужно смотреть реалистично.
То есть забить просто и не пытаться даже делать нормально декомпозицию? ну ладно.
Вспоминаю модули в magento 2
магенту это вообще страх и слезы.
Понятно что наследование лучше избежать.
причем тут наследование? В целом когда у вас есть модуль Users и еще десяток и все юзают сущность из этого бедного модуля Users, хотя им только айдишка нужна. И это самый лайтовый пример факапов.
Не понял, можно иметь CoreBundle, только называть так нельзя?
Суть не в названии, вы же это понимаете. Я сейчас говорю о разделении приложения на модули. То есть вы можете сделать какой-нибудь модуль Infrastructure, но там не должно быть сущностей и бизнес логики.
Вопервых проясним вопрос с терминами «темы» и «функциональность». По сути это должны быть синонимы. Во вторых ваши «пользователи» являются совокупностью разных функциональностей (и возможно должны быть разбиты), в частности это аутентификация, профили (иногда это разные профили, представьте себе убер где есть профиль пассажира и профиль водителя), есть сквозная функциональность (например у тех же профилей есть рейтинг, который неплохо выделяется в свой модуль) ну и т.д.
Во вторых на тему разделения проекта на модули (а бандлы это вид модуля) пишут книги еще с 70-х, и все сводится к тому что бы уменьшать связанность между ними и повышать cohesion. Лучше с этими вопросами попробуйте разобраться.
Скажем… типичная проблема людей, которую я наблюдал на проектах — желание разделить на бандлы и потом юзать нутро этих бандлов в других бандлах. Типа есть бандл «пользователи» и во всех остальных бандлах идут отсылки на сущность `User` из этого бандла, хотя в целом достаточно лишь айдишки (хотя логика тут ясна — так намного проще, особенно по началу, в плане выплевывания данных в шаблоны). Ну и всякие CommonBundle, CoreBundle и прочие UtilsBundle свидетельствуют о проблемах с декомпозицией на проекте.
Ну и в заключение — не надо делить проект на бандлы. Вообще. Бандлы нужны для реюза кода между проектами, что бы можно было их подключить к проекту и все. Та же аутентификация или восстановление пароля в целом неплохо обобщаются до бандла, но мне не известны примеры где это сделано хорошо (хотя скажем есть вариант подключить какой AuthN-server и не париться с бандлами, но это больше вообще к вопросу о расширении кругозора к тому как не писать код а юзать готовое).
Если вы хотите разделить проект — сделайте нэймспейс. Этого более чем достаточно.
Для этого надо погрузиться в историю и вспомнить откуда пошла фраза everything is an object. А пошла она из публикации Early history of smalltalk. Это был один (только один из 6-ти) принципов по которому проектировался smalltalk 78.
В целом же, все упирается в понятие объект, так как история развивалась так что теперь у этого понятия есть два определения — первое — объект как абстрактный тип данных, и объект как единица вычислений (метафора компьютера в сети, со своей приватной памятью и т.д.). Второе — это то что имеет ввиду Алан под "большие объекты". В одном из интервью он рассказывал, что ему не интересно нутро объектов, что суть только в коммуникации объектов и избавлении от данных (пряча их внутри объектов и не высовывая наружу).
Причем часто он дает отсылки к публикациям где похожие идеи с сокрытием данных за счет функциональной абстракции были продемонстрированы за счет использования лямбда исчислений к примеру.
То есть суть не в том что бы все было объектом, а в том что бы от данных избавиться. Дальше вся система выстраивается по принципам actor model. То есть правильнее называть "тру ооп" не парадигмой а моделью вычисления. Причем внутри объекта вы можете использовать что ФП (Erlang как пример) что классические процедурные подходы к которым все привыкли.
По источникам если вам интересно, можно начать вот с этого, продолжить на c2.wiki, посмотреть общение автора термина ООП и автора Erlang и о том как они восхваляют prolog и lisp и в крадце рассказывают историю ООП и отношение к нему (скажем последние лет 20 Алан больше в Meta языки ударился).
Вот если честно pattern matching в ФП(хотя я не силен в ФП, пока на стадии обучения) напоминает утиную типизацию
Ну вы очень упрощаете, да и что плохого в структурной типизации? У номинальных систем типов есть свои ограничения. Главное что бы язык позволял вам работать с этими конструкциями с сохранением максимальной информации о типах (а это прощай мутабельность).
а скорее в понимании кода
в том то и суть, объекты Алана — это немного выше уровнем нежели код. Представьте это как модуль, подсистему, сервис или, что там модно нынче, микросервис.
ведь давно существует принцип KISS
Существует распространенное мнение что KISS о том что бы делать то, что первое пришло в голову. Однако KISS это больше о проектировании систем так, что бы эту систему было просто эксплуатировать. В силу простоты принципа наверное, что я нахожу ироничным.
если мы возьмем предложенный Егором и пересмотрим синтаксис то что мы можем найти. Возьмем его пример и просто переложим синтаксис на другой язык — например Kotlin. У нас исчезает оператор new и код становится уже чуть менее "странным", такой код мы могли бы увидеть во многих языках (например javascript).
Что мне кажется странным так это то, сколько Егор тратит усилий, пишет статьи, общается с людьми. Да блин, у него в блоге как-то раз сам Алан Кей отписывался в комментах на темы "что он имел ввиду". Однако всякий раз он опять все путает и делает обработку данных на объектах, хотя идея объектов выше. А его проблемы в целом решит любой функциональный язык.
А если бы у вас была функция + и функция -, на которую можно было бы ссылаться и передавать как аргумент другим функциям? Ну и в целом если бы Java позволяла оперировать такими понятиями как функция.
Ну а штуки где закинуть файлик по ftp и т.д. в коммерческой разработке должны умереть (их можно заменить другими вещами где не надо код писать вообще).
да, пока не появляется состояние. И тут ближе или не ближе но человек уследить за этим уже не может так хорошо.
зачем вы тут искали сложную логику.
а мне непонятно к чему вы это привели. Данный пример никак не подтверждает вашу гипотезу о том что процедурный стиль естественный для человека и именно по этому мы можем наблюдать в большинстве проектов кашу из сеттеров и прочий мусор. Не подтверждает этот пример ничего просто потому что он не демонстрирует сам процедурный стиль. Повторюсь — какой бы подход вы не выбрали код будет примерно одинаков для таких вещей. Пишите вы на каком-нибудь meta-meta языке или Си, не важно.
Я предположу что у того как выглядит большая часть кода причина несколько иная нежели "нам так думать естественнее". Когда люди учатся они обычно смотрят на то, как это делают другие. Так или иначе формируется представление о том как надо делать дела, за счет практики это представление формируется в привычку, ну и опять же — никто не думает что делает. Так растет случайная сложность, связанность и т.д.
Что до за или против ООП — это глупый вопрос поскольку внутри вашего объекта может быть как тупой императивный код так и красивый декларативный. Проблема заключается в подмене понятий, которую сформировали опять же привычки и закрепленные в обществе убеждения что ООП это про классы.
вы сейчас привели в пример оркестрацию, без условий и какой-либо логики. тупо последовательность действий. Этот код будет выглядеть идентично вне зависимости от выбранного стиля.
А вы про какой ООП говорите? общепринятый или тот который от Алана Кея? Все же есть разница. Разница на уровне что ООП Кея было все же интереснее чем ООП которое было в Simula (да даже ооп в симуле было интереснее чем ООП в java), а поскольку из выживших и используемых языков из тех что подходят под определения Кея остался только Erlang… то лучше просто забить и смотреть в сторону всяких там F# и подобных (что-нибудь с сильной системой типов и упором на функциональную абстракцию а не на структурное программирование).
Может просто не надо сферических коней обсуждать? приводите конкретные примеры (и если можно не магенту), которые можно обсудить. Иначе это разговор ниочем.
p.s. да, моя ситуация такова что я выбираю решения и проекты, и я целенаправлено не выбираю проекты с магенту и прочими вордпрессами ибо считаю это неверной стратегией развития и реюза кода. Однако не стоит думать что мне не приходится оставлять себе "точки расширения" или что я всегда могу их подобрать так что бы оно было на все случаи жизни. Всего наперед не узнаешь. Но вот либы форкать что бы фичи добавлять мне не приходилось (разве что как PR к этим либам).
и это не мои проблемы если вы вдруг решили делать что-то что я не подразумевал когда делал библиотечку.
«Этот метод нельзя редактировать, приватный же.»
Если я форкнул библиотеку то скорее всего не для того что бы добавить в нее фичи которые мне нужны а что бы баг пофиксить. Иначе я не очень понимаю зачем использовать библиотеку которая не очень то мне подходит и при этом ее нельзя расширить.
Но так и ddd можно везде применять, только смысла от этого не прибавится.
для того что бы автор библиотеки мог следовать semver, ему нужно понимать какие изменения ломают обратную совместимость а какие нет. То есть у разработчика должно быть понятие "публичный интерфейс".
Если возможность "отнаследоваться и переопределись" не была заложена как часть этого публичного интерфейса, тем более если классы или методы были отмечены тегом @internal, разработчик не должен воспринимать это дело как публичный интерфейс и его право ломать обратную совместимость в этом месте в пределах минорного релиза.
Ну и опять же относительно фиксации версий — вы можете зафиксировать конкретную версию. И что, уже обновляться никогда не будете? Если вы пользуетесь исключительно публичным API высока вероятность что обратная совместимость будет поддерживаться довольно продолжительный период.
Вот пример: rulerz, основывается на «hoa/ruler»: "~2.0". И вполне работает.
Как это относится к теме дискуссии? вопервых hoa/ruler в целом предоставяет точки расширения, и это является публичным интерфейсом этой библиотеки. Это в нее заложено было, а потому за обратной совместимостью там следят. Потому опять же не понимаю причем тут оно.
если версия стала камнем преткновения
не версия, а необходимость поддержания обратной совместимости. Мне как автору библиотеки выгодно по максимуму уменьшить варианты использования библиотеки, так как иначе я не могу предсказать кому я чего могу сломать. И даже тот факт что я выкладываю библиотеку с лицензией вида "если я вам чего сломаю — сами виноваты" — это не отменяет того факта что ломать кому-то чего-то просто так это не очень хорошая идея.
20% это уже не мало, либо вы преувеличили. Что до "остальное выкинуть" — не выйдет. У всех это разные 20%. Да и опять же, вы уверены что вы не пользуетесь какими-то фичами потому что они вам не нужны, или вы просто о них не знаете?)
меняются. Эффекты от изменений изолированы на уровне обертки. Как пример — branch by abstraction как раз таки пример таких оберток для рефакторинга планомерного.
А так да, придется тесты писать и думать что делаете, магии не бывает.
первое что приходит на ум — билдеры. Второе — какие-то internal штуки которые хочется защитить от того, что бы их кто-то еще юзал (актуально если вы пишите библиотеки публичные).
еще раз — не надо делить проект на бандлы. Бандлы для реюза кода между проектами, инфраструктура какая-то, обобщенный функционал. Например вам надо быстро прикрутить websockets — ставим centrifugo bundle. Бизнес логики в бандлах быть не должно.
То есть забить просто и не пытаться даже делать нормально декомпозицию? ну ладно.
магенту это вообще страх и слезы.
причем тут наследование? В целом когда у вас есть модуль
Usersи еще десяток и все юзают сущность из этого бедного модуляUsers, хотя им только айдишка нужна. И это самый лайтовый пример факапов.Суть не в названии, вы же это понимаете. Я сейчас говорю о разделении приложения на модули. То есть вы можете сделать какой-нибудь модуль
Infrastructure, но там не должно быть сущностей и бизнес логики.Во вторых на тему разделения проекта на модули (а бандлы это вид модуля) пишут книги еще с 70-х, и все сводится к тому что бы уменьшать связанность между ними и повышать cohesion. Лучше с этими вопросами попробуйте разобраться.
Скажем… типичная проблема людей, которую я наблюдал на проектах — желание разделить на бандлы и потом юзать нутро этих бандлов в других бандлах. Типа есть бандл «пользователи» и во всех остальных бандлах идут отсылки на сущность `User` из этого бандла, хотя в целом достаточно лишь айдишки (хотя логика тут ясна — так намного проще, особенно по началу, в плане выплевывания данных в шаблоны). Ну и всякие CommonBundle, CoreBundle и прочие UtilsBundle свидетельствуют о проблемах с декомпозицией на проекте.
Ну и в заключение — не надо делить проект на бандлы. Вообще. Бандлы нужны для реюза кода между проектами, что бы можно было их подключить к проекту и все. Та же аутентификация или восстановление пароля в целом неплохо обобщаются до бандла, но мне не известны примеры где это сделано хорошо (хотя скажем есть вариант подключить какой AuthN-server и не париться с бандлами, но это больше вообще к вопросу о расширении кругозора к тому как не писать код а юзать готовое).
Если вы хотите разделить проект — сделайте нэймспейс. Этого более чем достаточно.
Для этого надо погрузиться в историю и вспомнить откуда пошла фраза everything is an object. А пошла она из публикации Early history of smalltalk. Это был один (только один из 6-ти) принципов по которому проектировался smalltalk 78.
В целом же, все упирается в понятие объект, так как история развивалась так что теперь у этого понятия есть два определения — первое — объект как абстрактный тип данных, и объект как единица вычислений (метафора компьютера в сети, со своей приватной памятью и т.д.). Второе — это то что имеет ввиду Алан под "большие объекты". В одном из интервью он рассказывал, что ему не интересно нутро объектов, что суть только в коммуникации объектов и избавлении от данных (пряча их внутри объектов и не высовывая наружу).
Причем часто он дает отсылки к публикациям где похожие идеи с сокрытием данных за счет функциональной абстракции были продемонстрированы за счет использования лямбда исчислений к примеру.
То есть суть не в том что бы все было объектом, а в том что бы от данных избавиться. Дальше вся система выстраивается по принципам actor model. То есть правильнее называть "тру ооп" не парадигмой а моделью вычисления. Причем внутри объекта вы можете использовать что ФП (Erlang как пример) что классические процедурные подходы к которым все привыкли.
По источникам если вам интересно, можно начать вот с этого, продолжить на c2.wiki, посмотреть общение автора термина ООП и автора Erlang и о том как они восхваляют prolog и lisp и в крадце рассказывают историю ООП и отношение к нему (скажем последние лет 20 Алан больше в Meta языки ударился).
Ну вы очень упрощаете, да и что плохого в структурной типизации? У номинальных систем типов есть свои ограничения. Главное что бы язык позволял вам работать с этими конструкциями с сохранением максимальной информации о типах (а это прощай мутабельность).
в том то и суть, объекты Алана — это немного выше уровнем нежели код. Представьте это как модуль, подсистему, сервис или, что там модно нынче, микросервис.
Существует распространенное мнение что KISS о том что бы делать то, что первое пришло в голову. Однако KISS это больше о проектировании систем так, что бы эту систему было просто эксплуатировать. В силу простоты принципа наверное, что я нахожу ироничным.
если мы возьмем предложенный Егором и пересмотрим синтаксис то что мы можем найти. Возьмем его пример и просто переложим синтаксис на другой язык — например Kotlin. У нас исчезает оператор
newи код становится уже чуть менее "странным", такой код мы могли бы увидеть во многих языках (например javascript).Что мне кажется странным так это то, сколько Егор тратит усилий, пишет статьи, общается с людьми. Да блин, у него в блоге как-то раз сам Алан Кей отписывался в комментах на темы "что он имел ввиду". Однако всякий раз он опять все путает и делает обработку данных на объектах, хотя идея объектов выше. А его проблемы в целом решит любой функциональный язык.
А если бы у вас была функция
+и функция-, на которую можно было бы ссылаться и передавать как аргумент другим функциям? Ну и в целом если бы Java позволяла оперировать такими понятиями как функция.очень часто люди кидаются в разработку кастомных решений хотя их задачу покрывают какие-нибудь гугл доки и запир.
github.com/reljicd/spring-boot-blog — ну вот посмотрите. Как по мне не сложнее всяких там ларавелей и симфони и при этом не php.
Ну а штуки где закинуть файлик по ftp и т.д. в коммерческой разработке должны умереть (их можно заменить другими вещами где не надо код писать вообще).
да, пока не появляется состояние. И тут ближе или не ближе но человек уследить за этим уже не может так хорошо.
а мне непонятно к чему вы это привели. Данный пример никак не подтверждает вашу гипотезу о том что процедурный стиль естественный для человека и именно по этому мы можем наблюдать в большинстве проектов кашу из сеттеров и прочий мусор. Не подтверждает этот пример ничего просто потому что он не демонстрирует сам процедурный стиль. Повторюсь — какой бы подход вы не выбрали код будет примерно одинаков для таких вещей. Пишите вы на каком-нибудь meta-meta языке или Си, не важно.
Я предположу что у того как выглядит большая часть кода причина несколько иная нежели "нам так думать естественнее". Когда люди учатся они обычно смотрят на то, как это делают другие. Так или иначе формируется представление о том как надо делать дела, за счет практики это представление формируется в привычку, ну и опять же — никто не думает что делает. Так растет случайная сложность, связанность и т.д.
Что до за или против ООП — это глупый вопрос поскольку внутри вашего объекта может быть как тупой императивный код так и красивый декларативный. Проблема заключается в подмене понятий, которую сформировали опять же привычки и закрепленные в обществе убеждения что ООП это про классы.
А потому ваш пример не подходит для обсуждения.
Может просто не надо сферических коней обсуждать? приводите конкретные примеры (и если можно не магенту), которые можно обсудить. Иначе это разговор ниочем.
p.s. да, моя ситуация такова что я выбираю решения и проекты, и я целенаправлено не выбираю проекты с магенту и прочими вордпрессами ибо считаю это неверной стратегией развития и реюза кода. Однако не стоит думать что мне не приходится оставлять себе "точки расширения" или что я всегда могу их подобрать так что бы оно было на все случаи жизни. Всего наперед не узнаешь. Но вот либы форкать что бы фичи добавлять мне не приходилось (разве что как PR к этим либам).
и это не мои проблемы если вы вдруг решили делать что-то что я не подразумевал когда делал библиотечку.
Если я форкнул библиотеку то скорее всего не для того что бы добавить в нее фичи которые мне нужны а что бы баг пофиксить. Иначе я не очень понимаю зачем использовать библиотеку которая не очень то мне подходит и при этом ее нельзя расширить.
Некорректное сравнение.
желание расширять функционал через наследование — плохое желание. В 90% случаев есть варианты лучше.
для того что бы автор библиотеки мог следовать semver, ему нужно понимать какие изменения ломают обратную совместимость а какие нет. То есть у разработчика должно быть понятие "публичный интерфейс".
Если возможность "отнаследоваться и переопределись" не была заложена как часть этого публичного интерфейса, тем более если классы или методы были отмечены тегом
@internal, разработчик не должен воспринимать это дело как публичный интерфейс и его право ломать обратную совместимость в этом месте в пределах минорного релиза.Ну и опять же относительно фиксации версий — вы можете зафиксировать конкретную версию. И что, уже обновляться никогда не будете? Если вы пользуетесь исключительно публичным API высока вероятность что обратная совместимость будет поддерживаться довольно продолжительный период.
Как это относится к теме дискуссии? вопервых hoa/ruler в целом предоставяет точки расширения, и это является публичным интерфейсом этой библиотеки. Это в нее заложено было, а потому за обратной совместимостью там следят. Потому опять же не понимаю причем тут оно.
не версия, а необходимость поддержания обратной совместимости. Мне как автору библиотеки выгодно по максимуму уменьшить варианты использования библиотеки, так как иначе я не могу предсказать кому я чего могу сломать. И даже тот факт что я выкладываю библиотеку с лицензией вида "если я вам чего сломаю — сами виноваты" — это не отменяет того факта что ломать кому-то чего-то просто так это не очень хорошая идея.
20% это уже не мало, либо вы преувеличили. Что до "остальное выкинуть" — не выйдет. У всех это разные 20%. Да и опять же, вы уверены что вы не пользуетесь какими-то фичами потому что они вам не нужны, или вы просто о них не знаете?)
именно так. Иначе никакой гарантии что ваше "расширение" не сломается в следующем релизе.
И если под "расширением" вы подразумеваете extends — специально для все все классы с интерфейсами сделать final
А так да, придется тесты писать и думать что делаете, магии не бывает.
первое что приходит на ум — билдеры. Второе — какие-то internal штуки которые хочется защитить от того, что бы их кто-то еще юзал (актуально если вы пишите библиотеки публичные).