🚦Возвращаем или выкидываем
Сейчас будет серия постов, где подытожу опросники выше.
Самый крутой показатель в этом опроснике – 36% хотели бы возвращать, но выбрасывают.
Чаще всего, это связано с тем, что в их языке принято выбрасывать ошибки, но люди понимают, что "стандарт" не всегда "правильный путь".
Еще, в комментариях к посту мы с @highloadzone (спасибо тебе большое за дискуссию) устроили массивное обсуждение на тему ошибок и трейсов, советую почитать.
Там я пришел к следующей мысли:
Реальные "ошибки" – это те, которым мы разрешаем положить наше приложение, и их надо выкидывать.
А все остальные "ошибки" надо рассматривать скорее как "неуспех" / "неудачу", и их надо возвращать.
Если следовать такому пути, вы получите лучшее из двух миров:
. Опасные ошибки будут перехватываться где-то на самом верху стэка и иметь право даже положить приложение;
. А вот "неудача", которую просто синтасически удобно выразить в форме структуры Error, всегда возвращается из функций, потому что нам эту неудачу придется 1 и более раз каким-то образом обработать.
Я понял, что тема крайне большая, поэтому посвящу ее отдельный раздел в книге ФОП, где расскажу про принципы, заложенные Робом Пайком в дизайн Go, error handling функциональных языков, проблемы hidden control flow и Railway Oriented Programming.
Самый крутой показатель в этом опроснике – 36% хотели бы возвращать, но выбрасывают.
Чаще всего, это связано с тем, что в их языке принято выбрасывать ошибки, но люди понимают, что "стандарт" не всегда "правильный путь".
Еще, в комментариях к посту мы с @highloadzone (спасибо тебе большое за дискуссию) устроили массивное обсуждение на тему ошибок и трейсов, советую почитать.
Там я пришел к следующей мысли:
Реальные "ошибки" – это те, которым мы разрешаем положить наше приложение, и их надо выкидывать.
А все остальные "ошибки" надо рассматривать скорее как "неуспех" / "неудачу", и их надо возвращать.
Если следовать такому пути, вы получите лучшее из двух миров:
. Опасные ошибки будут перехватываться где-то на самом верху стэка и иметь право даже положить приложение;
. А вот "неудача", которую просто синтасически удобно выразить в форме структуры Error, всегда возвращается из функций, потому что нам эту неудачу придется 1 и более раз каким-то образом обработать.
Я понял, что тема крайне большая, поэтому посвящу ее отдельный раздел в книге ФОП, где расскажу про принципы, заложенные Робом Пайком в дизайн Go, error handling функциональных языков, проблемы hidden control flow и Railway Oriented Programming.
Комментарии: 122
А
кто тут автор вот этого? https://fop.davidshekunts.ru/origins/you-have-never-used-oop у меня к Вам много вопросов ! )
🦾
🦾
А
А
А
🦾
Да, заголовок намеренно провакационный, про, "все объекты и обмениваются сообщениями" – вы абсолютно правы, но самая важная часть "канонического" ООП это то, что при этом все "объекты" инкапсулируют как поведение, так и данные
Когда вы создаете ...Service, который управляет другими моделями, вы теряете инкапсуляцию этих моделей и начинаете работать с ними как раз таки более в процедурном стиле (о котором и есть ФОП), поэтому я говорю о том, что это ближе к ФОП, чем к ООП
Потому что ООП – это в первую очередь архитектура, а не синтаксис (есть множество примеров, где в рамках каких-нибудь Haskell / Elixir пишут чисто ООП код, засчет объединения данных и поведения)
Когда вы создаете ...Service, который управляет другими моделями, вы теряете инкапсуляцию этих моделей и начинаете работать с ними как раз таки более в процедурном стиле (о котором и есть ФОП), поэтому я говорю о том, что это ближе к ФОП, чем к ООП
Потому что ООП – это в первую очередь архитектура, а не синтаксис (есть множество примеров, где в рамках каких-нибудь Haskell / Elixir пишут чисто ООП код, засчет объединения данных и поведения)
🦾
Notion + react-notion-x + Vercel
Я буду писать на Хабру статью про то, как это сделать, но вы можете просто взять мой репозиторий (https://github.com/Dionid/fop-site) и повторить тоже самое и абсолютно бесплатно
Я буду писать на Хабру статью про то, как это сделать, но вы можете просто взять мой репозиторий (https://github.com/Dionid/fop-site) и повторить тоже самое и абсолютно бесплатно
А
🦾
Возможно, и это будет называть POJO, а если именно из мира ООП, то Anemic / Slim Model
Главное, что я хочу, чтобы поняли читатели – это не канонический ООП, это его вариация, причем практически с другой стороны
То есть, если повсеместно использовать Anemic / Slim Model + Service Object вы получите процедрное программирование)
Но встает вопрос: а зачем вообще тогда использовать ООП? И если человеку этого не хочется, то он может посмотреть в сторону процедруного программирования, НО мало материалов, которые его достаточно хорошо описывают + он устарел, поэтому я создал ФОП, в рамках которого взял все самое лучшее их процедурщины, струтрировал это и добавил туда функциональщины
Главное, что я хочу, чтобы поняли читатели – это не канонический ООП, это его вариация, причем практически с другой стороны
То есть, если повсеместно использовать Anemic / Slim Model + Service Object вы получите процедрное программирование)
Но встает вопрос: а зачем вообще тогда использовать ООП? И если человеку этого не хочется, то он может посмотреть в сторону процедруного программирования, НО мало материалов, которые его достаточно хорошо описывают + он устарел, поэтому я создал ФОП, в рамках которого взял все самое лучшее их процедурщины, струтрировал это и добавил туда функциональщины
А
🦾
А
А
А
🦾
А
А
🦾
Тогда в большинстве языков у вас число будет просто ссылкой на память со значением числа, а не объектам
У него не будет никаких методов, это просто будет голое число
Поэтому, наверное, вы хотите, чтобы мы взяли именно языки, где число превращают в объект с методами?
У него не будет никаких методов, это просто будет голое число
Поэтому, наверное, вы хотите, чтобы мы взяли именно языки, где число превращают в объект с методами?
А
А
🦾
А
🦾
Тогда смотрите, я часто пишу в книге "синтаксис не есть парадигма / архитектура" и то, что ООП и ФОП я описываю именно в качестве "архитектуры", которую можно использовать как на языке с встроенным ООП, так и на чисто функциональном / процедурном языке
Поэтому да, число и любой кусок данных может быть объектом с методами, это будет ООП синтаксис, но при этом будет ли кодовая база использовать ООП архитектуру – это уже выбор каждого
Поэтому да, число и любой кусок данных может быть объектом с методами, это будет ООП синтаксис, но при этом будет ли кодовая база использовать ООП архитектуру – это уже выбор каждого
А
🦾
Начиная с этой главы я и рассказываю, что такое "ООП как архитектура"
А
понял, там есть отсылка на предыдущую статью https://fop.davidshekunts.ru/origins/you-dont-know-oop сейчас, сбегаю, прочитаю и вернусь )
А
А
🦾
Я разделял как "синтаксис" (например, для в Java и JS все – объект) и парадигма / архитектура (потому что у них много переплетений), но даже эти понятия можно разделить (мне бы пришлось слишком много описывать тонких раличий, поэтому я объединил эти понятия)
А
🦾
А
А
🦾
🦾
А
А
🦾
А
А
вот у нас есть приложение, мы должны проверить, является ли User чем то, например администратором. в каноническом ООП как бы Вы это сделали? прям максимально упрощено. если что, раскроем потом в нужном месте более подробно, но вот прям у нас такая задача, пусть это будет веб сайт, или приложение, и чтобы показать пользователю ссылку, кнопку для перехода "поуправлять чем то", нам надо проверить является ли пользователь администратором. Как бы Вы это сделали?
🦾
ООП синтаксиса – конструкции языка и его устроство, например, что число это объект с методами и использование их методов через dot-notation (number.toString())
ООП парадигма – набор правил написания кода, включающее 4 основных столпа (инкапсуляция, абстракция, наследование и полиморфизм)
ООП архитектура – разделение бизнес сущностей на "объекты" инкапсулирующие логику и поведение (User.changeEmail(newEmail))
ФОП синтаксис – такого нет, ФОП разрабатон для мультипарадигмальных языков, а значит позволяет использовать любой синтаксис
ФОП парадигма – набор правл написания кода, включающий в себя 3 столпа (Пазделение данных и поведения, Композиция, Полиморфизм на интерфейсах)
ФОП архитектура – разделение бизнес-сущностей на объекты, хранящие только данные, и use cases использующие любые данные для воспроизведения бизнес-логики (changeUserEmail(user, newEmail))
ООП парадигма – набор правил написания кода, включающее 4 основных столпа (инкапсуляция, абстракция, наследование и полиморфизм)
ООП архитектура – разделение бизнес сущностей на "объекты" инкапсулирующие логику и поведение (User.changeEmail(newEmail))
ФОП синтаксис – такого нет, ФОП разрабатон для мультипарадигмальных языков, а значит позволяет использовать любой синтаксис
ФОП парадигма – набор правл написания кода, включающий в себя 3 столпа (Пазделение данных и поведения, Композиция, Полиморфизм на интерфейсах)
ФОП архитектура – разделение бизнес-сущностей на объекты, хранящие только данные, и use cases использующие любые данные для воспроизведения бизнес-логики (changeUserEmail(user, newEmail))
🦾
В каноничном ООП, у меня должен был быть объект, который инкапсулирует данные нужные для исполнения логики и поведение
Простой вариант – `user.isAdmin()`, более сложный `userPermission.checkUserIsAdmin()` где у userPermission внутри есть ссылка на нужного пользователя и он обратиться к его методу типа user.getRole()
Простой вариант – `user.isAdmin()`, более сложный `userPermission.checkUserIsAdmin()` где у userPermission внутри есть ссылка на нужного пользователя и он обратиться к его методу типа user.getRole()
🦾
В рамках ФОП у меня просто будет функция isUserAdmin(...) куда можно скормить любой из объектов, например isUserAdmin(user) или isUserAdmin(user, role) если данные лежат как-то раздельно
В user буду лежать просто данные, а вся логика в функциях типа isUserAdmin
В user буду лежать просто данные, а вся логика в функциях типа isUserAdmin
А
А
🦾
Возвращать роль пользователя
Это может произойти множеством методов: (1) возможно это просто тестовое свойство на пользователе, тогда он просто просто отдаст его, (2) возможно, оно лежит в отдельном объекте, тогда оно пойдет в него и достанет (тоже через метод), (3) возможно это свойство в виде цифры, которую User смапит к строчке, (4) возможно через этот метод он отдает не все роли, есть еще getSuperRole, где он отдает супер роли, (5) возможно, этот метод отдает массив ролей, а если хочется основную, тогда будет getMainRole
А возможно, сначала будет первый вариант, а потом с усложнением системы добавляться каждый последующий
Почему мы делаем достаем именно через метод getRole, а не напрямую user.role, потому что это будет нарушение инкапсуляции, которое заберет самое большое преимущество ООП: с развитием метода getRole нам не предтся переписывать его снаружи, а только внутри (Open Close Principle или типа того)
Это может произойти множеством методов: (1) возможно это просто тестовое свойство на пользователе, тогда он просто просто отдаст его, (2) возможно, оно лежит в отдельном объекте, тогда оно пойдет в него и достанет (тоже через метод), (3) возможно это свойство в виде цифры, которую User смапит к строчке, (4) возможно через этот метод он отдает не все роли, есть еще getSuperRole, где он отдает супер роли, (5) возможно, этот метод отдает массив ролей, а если хочется основную, тогда будет getMainRole
А возможно, сначала будет первый вариант, а потом с усложнением системы добавляться каждый последующий
Почему мы делаем достаем именно через метод getRole, а не напрямую user.role, потому что это будет нарушение инкапсуляции, которое заберет самое большое преимущество ООП: с развитием метода getRole нам не предтся переписывать его снаружи, а только внутри (Open Close Principle или типа того)
А
А
во вторых данные надо загружать лениво, поэтому у нас рожденный пользователь не весь сразу а частично, потом нам надо например получить список ролей чтобы узнать является ли он админом, кто-то должен сходить в базу вернуть пользователю эти данные, и он тогда их вернет UserPermission'у.
А
А
А
🦾
Честно говоря, не совсем понимаю как бы о чем вы: вы спросили про getRole, я ответил почему именно getRole в каноническом ООП, а не просто сходить и достать нужные данные
В ФОП, я бы мог позволить себе спокойно сделать запрос в БД и достать нужные данные, если бы это становилось сложнее, я бы вынес отдельную функцию getUserRole и делал бы там то, что нужно с любым кол-вом объектов, которые меня интересуют, не связываю их друг с другом
В ФОП, я бы мог позволить себе спокойно сделать запрос в БД и достать нужные данные, если бы это становилось сложнее, я бы вынес отдельную функцию getUserRole и делал бы там то, что нужно с любым кол-вом объектов, которые меня интересуют, не связываю их друг с другом
🦾
А
А
А
А
я просто что хочу сказать, очень у многих есть большие при большие предрассудки по поводу ООП, а любители архитектур так вообще "больные" люди. То что можно сделать в 20 строк кода "процедурным" стилем, делают в "ООП" но для этого надо 2000 строк кода написать. Это же блин бред.
А
🦾
И вы будете абсолютно правы) В этом и суть: нашим ООП объектом должено быть само приложение / библиотека / модуль, как угодно
Я пишу об этом в следующей статье
Я пишу об этом в следующей статье
🦾
В чем будет отличие между #1 и #2 вот по этой ссылке?
https://gist.github.com/Dionid/616eb8915d1c2b9bb74a56342cf3dbac
https://gist.github.com/Dionid/616eb8915d1c2b9bb74a56342cf3dbac
🦾
Еще раз уточню: OOП + Anemic / Slim model + Service Object с точки зрения архитектуры это ближе к процедурному программированию, чем к каноничному ООП, хоть по-прежнему может называть "ООП" (потому что использует его синтаксис и может использовать парадигму, но архитектурно уже не то)
🦾
А
А
если принять как утверждение что каноничный ООП, это обязательно объекты, каждый из которых отвечает только за себя, и в нем не должно быть объектов с открытыми данными, и объектов без данных. И если считать что ООП это вот только в таких узких рамках, то да соглашусь с Вами, но так программы писать нельзя на 99% случаев. Ну или можно, но 99% кода программы будет бесполезной херней, для доступа данных из объекта, маппинга и так далее. Поэтому ТОЛЬКО чистого канонического ООП нигде никогда не будет.
А
🦾
И проблема ООП именно в вашей последней фразе: "программы на каноничном ООП нигде и никогда не будет"
НО абсолютно процедурная программа вполне себе возможна
Тогда вопрос: зачем следовать парадигме, которая неполная и заставляет тебя прибегать к хакам и обходу самой парадигмы, при этом накладывает на тебя ограничения и усложнения для решения которых тебе приходится выучивать еще дополнительные паттерны (SOLID – это пробка созданная ООП для решения проблем самого ООП, их нет в функциольной и процедурных парадигмах), когда можно просто НЕ использовать вообще ООП и использовать что-то, что покрывает 100% ваших кейсов?
Я против ООП на ...Service потому что это микс с процедурным программированием, который при этом оставляет все проблемы ООП
Я предлагаю просто отказаться от него и если вам приятно писать используя ...Service, значит, скорее всего, вы можете полностью перейти на ФОП и избавиться от всех проблем, которые могут быть в ООП + получить доступ к куче всяких фишек из функциональщины и процедурщины
НО абсолютно процедурная программа вполне себе возможна
Тогда вопрос: зачем следовать парадигме, которая неполная и заставляет тебя прибегать к хакам и обходу самой парадигмы, при этом накладывает на тебя ограничения и усложнения для решения которых тебе приходится выучивать еще дополнительные паттерны (SOLID – это пробка созданная ООП для решения проблем самого ООП, их нет в функциольной и процедурных парадигмах), когда можно просто НЕ использовать вообще ООП и использовать что-то, что покрывает 100% ваших кейсов?
Я против ООП на ...Service потому что это микс с процедурным программированием, который при этом оставляет все проблемы ООП
Я предлагаю просто отказаться от него и если вам приятно писать используя ...Service, значит, скорее всего, вы можете полностью перейти на ФОП и избавиться от всех проблем, которые могут быть в ООП + получить доступ к куче всяких фишек из функциональщины и процедурщины
🦾
Потому что решение о том будет ли ваш код на ООП или процедурным влияет на то, как каждый член команды будет писать следующую функцию
1. Если вы примите решение писать на каноничном ООП, значит я могу всегда знать что любая вещь связанная с User будет на нем
2. Если мы используем процедурный подход, значит, я буду искать функцию, которая решает какой-то конкретный кейс и буду знать, что работа над User может происходить в куче мест
3. Если используем НЕканоничный ООП, то у меня часть будет на User и часть разбросана в разных Service
В первом и втором случае, я знаю куда дальше писать логику
В третьем, я каждый раз должен догадаться где ее хорошо было бы разместить и вот эта неопределенность мне дико не нравится
1. Если вы примите решение писать на каноничном ООП, значит я могу всегда знать что любая вещь связанная с User будет на нем
2. Если мы используем процедурный подход, значит, я буду искать функцию, которая решает какой-то конкретный кейс и буду знать, что работа над User может происходить в куче мест
3. Если используем НЕканоничный ООП, то у меня часть будет на User и часть разбросана в разных Service
В первом и втором случае, я знаю куда дальше писать логику
В третьем, я каждый раз должен догадаться где ее хорошо было бы разместить и вот эта неопределенность мне дико не нравится
А
так, смотрите, чел придумал клевую штуку, создавать объекты, посылать им сообщения. Все. Дальше уже напридумывали черти что, это ладно, но главное что напридумывали себе ограничения, за которые заходить нельзя, иначе ты не тру ООП программист, фу таким быть и вон из профессии.
🦾
Кстати, каноничный ООП частично возможен: если вы строго действуете по ООП, то засчет Агрегатов вы будете способны сделать ациклические графы со сторогой зависимостью и наличием методов только на объектах
Но это невероятно сложно (настолько, что возможно только на небольшом объеме)
Но это невероятно сложно (настолько, что возможно только на небольшом объеме)
А
🦾
А
А
А
А
А
🦾
Ну, вот тут уже выбор каждого
Я понял, что микс с ООП дает мне больше проблем, чем когда я пишу полностью процедурно / функционально, потому что я иду по конкретному набору правил:
1. Данные не имеют поведения
2. Все функции могут использовать все данные
Я не ожидаю, что часть поведения будет на данных, а часть где-то в ...Service
Когда я пишу функцию и мне нужно что-то сделать с данными первый раз я сделаю это прямо в этой функции и только при повторении контекста я вынесу эту функцию в библиотеку (WYNWYN)
В противовес ООП, где люди попытаются операции, которые происходят всего один раз сразу же вынести их в Model / Repository / Service или еще куда-то превращая их в God Object, а после этого, когда нужно сделать примерно тоже самое будут модифицировать существующий метод, потенциально сломав что-то уже работающее, или же создадут новый увеличив размер God Object
Я понял, что микс с ООП дает мне больше проблем, чем когда я пишу полностью процедурно / функционально, потому что я иду по конкретному набору правил:
1. Данные не имеют поведения
2. Все функции могут использовать все данные
Я не ожидаю, что часть поведения будет на данных, а часть где-то в ...Service
Когда я пишу функцию и мне нужно что-то сделать с данными первый раз я сделаю это прямо в этой функции и только при повторении контекста я вынесу эту функцию в библиотеку (WYNWYN)
В противовес ООП, где люди попытаются операции, которые происходят всего один раз сразу же вынести их в Model / Repository / Service или еще куда-то превращая их в God Object, а после этого, когда нужно сделать примерно тоже самое будут модифицировать существующий метод, потенциально сломав что-то уже работающее, или же создадут новый увеличив размер God Object
🦾
Опять же и в рамках ООП можно сохранить WYNWYN, НО чаще всего, джуны или наоборот ООП-шники сектанты не будут этого делать, потому что у них есть четко заданная мысль: если это относится к какому-то объекту, значит, должно быть на нем, неважно, что используется всего 1 раз в 1 месте
Я не рассчитываю, что все мои коллеги будут достаточно грамотными, чтобы соблюдать правильно делать выбор, поэтому делаю проще: убираю выбор, указав четкие границы (разделение данных и поведения)
И я считаю, что программы во много раз понятнее и надежнее, когда в них больше повторения кода, чем когда бездумно пытаются соблюдать DRY, который тоже мало кто понимает (об этом тоже в WYNWYN)
Я не рассчитываю, что все мои коллеги будут достаточно грамотными, чтобы соблюдать правильно делать выбор, поэтому делаю проще: убираю выбор, указав четкие границы (разделение данных и поведения)
И я считаю, что программы во много раз понятнее и надежнее, когда в них больше повторения кода, чем когда бездумно пытаются соблюдать DRY, который тоже мало кто понимает (об этом тоже в WYNWYN)
А
согласен с Вами, но я поигрался в разные концепции, сейчас мне без разницы как меня назовут :) я буду миксовать и использовать все лучше оттуда, оттуда и оттуда :) если мне нужен объект, который что-то делает, я сделаю объект и буду его просить что-то для меня делать, если мой код процедурно будет размером 30 строк кода, а ООПшый 300 строк кода, я сделаю в процедурном стиле, много где, особенно на фронте я собираю из разных кучек с помощью функционального программирования в одно целое, потому что это удобно. я за эффективность во всем.
🦾