"расширять поведение системы не меняя код" - это как бы суть SOLID и в частности OCP. Дальше - если уж менять код то код должен меняться по одной и той же причине (SRP), взялся выстраивать полиморфизм - следи за контрактами (LSP), проектируй контракты под тех кто будет ими пользоваться, что бы удобно было (ISP), что бы уменьшить вероятность каскадных изменений инвертируй зависимости (DIP) ну и и.д.

ну и до всех этих SOLID была еще пачка принципов от дяди боба - это и принцип стабильных зависимостей, и принцип ацикличных зависимостей, принцип абстрактных зависимостей и еще парочка

если так смотреть на вещи значит что язык не должен позволять тебе нарушать LSP но он позволяет

а это не про LSP

LSP о том могут ли твои Map и List входить в одну иерархию типов или нет

OOP should really only have two keywords: "new" and "return": Переизобретают фп

LSP это про проверку качества абстракций

https://www.youtube.com/watch?v=US8QG9I1XW0

про контракты, ну там инварианты (если ты стэйт меняешь), прекондишены и пост кондишены...

Есть языки, которые имеют это свойство?

OOP should really only have two keywords: "new" and "return": Переизобретают фп

Это точка зрения скорее не изобретение а дополнение, ооп как функциональное++, в фп функции first class citezens, их можно передавать куда то и вызывать, т.е. это своего рода обьект с одним методом. А ооп Егор предлагает рассматривать как обьекты, с которыми нужно обращатся как с функциями но у этих функций можно вызвать не один метод, а несколько.

Это точка зрения скорее не изобретение а дополнение, ооп как функциональное++, в фп функции first class citezens, их можно передавать куда то и вызывать, т.е. это своего рода обьект с одним методом. А ооп Егор предлагает рассматривать как обьекты, с которыми нужно обращатся как с функциями но у этих функций можно вызвать не один метод, а несколько.

Вот только в его примерах всегда один метод ? (да и >=2 (где 2 там и 5) метода это путь к нарушению srp)

LSP

Вот только в его примерах всегда один метод ? (да и >=2 (где 2 там и 5) метода это путь к нарушению srp)

В примерах у него, разные утилитные классы которые делают что то одно, поэтому и один метод, а если брать что то посложнее то будет уже и 2 и 3 метода. Смотря из какого контекста исходить сколько слоев абстракции можно сделать, можно напилить и кучу мелких обьектов сделать несколько слоев, можно сделать слоев поменьше но тогда пространства для манёвра в случае изменений будет меньше, но для множества слоев тоже нужно время всё продумать... Нужно соблюдать какой то баланс но для этого нужно чутье

Да

Замена родителя подтипом не должна привести к неправильной работе

Можешь ли ты сделать подтип, который все сломает?

правило is a

Так что значит "lsp это свойство языка"?

Лсп про то, что это должно быть всегда корректно

А не про возможность, ну

Можешь ли ты сделать подтип, который все сломает?

lsp это про контракты

Это точка зрения скорее не изобретение а дополнение, ооп как функциональное++, в фп функции first class citezens, их можно передавать куда то и вызывать, т.е. это своего рода обьект с одним методом. А ооп Егор предлагает рассматривать как обьекты, с которыми нужно обращатся как с функциями но у этих функций можно вызвать не один метод, а несколько.

Сильно заблуждаетесь товарищ. В его высказывании я лишь увидел использование объекта как «контейнера», а контейнеры в фп повсюду, самых разных форм

При этом контейнеры по своему роду формализованы

Сильно заблуждаетесь товарищ. В его высказывании я лишь увидел использование объекта как «контейнера», а контейнеры в фп повсюду, самых разных форм

Как мне кажется там как раз было наоборот, уход от обьекта как от контейнера с данными, от "что ты можешь сделать с данными" к "кто ты такой"

Ну вот как раз формализации они определяют кто ты такой, а что ты можешь делать с данными это функции работающие с этими контейнерами, а не сами контейнеры

На Википедии все правильно

Ну конкретно в той фразе

В фп языках по сути единственный способ писать бизнес код это DDD, интерфейсы твоих функций определяют что ты можешь делать с данными в контексте domain, а сами данные выражены полностью с помощью ADT т.е находятся в запакованном виде который отражает бизнес правила и если правильно смоделировано всё, то может принимать только валидные значения

Сильно заблуждаетесь товарищ. В его высказывании я лишь увидел использование объекта как «контейнера», а контейнеры в фп повсюду, самых разных форм

если смотреть с позиции рантайма то разницы между ФП и ООП практически нет. и там и там функции и структуры данных

просто в ООП любят стэйт (по привычке) и любят дата шеринг между модулями (потому что привычки) а в ФП головы не так забиты говном

ну или этот самый дата шэринг намного более явно выражен в коде

короч пофиг, для меня ООП это эктор модел а не классы. а эктор модел с ФП хорошо дружат

если смотреть с позиции рантайма то разницы между ФП и ООП практически нет. и там и там функции и структуры данных

Ну как бы да, с позиции компилятора только все сильно по-другому)

Ну как бы да, с позиции компилятора только все сильно по-другому)

ну я бы не стал компилятор рассматривать как что-то эдакое. Если мы не касаемся вопросов производитеольности и системы типов, то если говорить про код то мне важнее как мысль выражается

а с учетом того что, как там кей говорил, "я просто принял для себя объект как наименьший интересующий меня субъект системы, как компьютер в сети или клетка" То есть что внутри объекта - фиалетово. Можно воспринимать как объект процесс, микротред, корутину, скоуп модуля... что хочешь

внутри можно хоть ФП, хоть структуроное программирование юзать. Но людям проще классы.

а с учетом того что, как там кей говорил, "я просто принял для себя объект как наименьший интересующий меня субъект системы, как компьютер в сети или клетка" То есть что внутри объекта - фиалетово. Можно воспринимать как объект процесс, микротред, корутину, скоуп модуля... что хочешь

Ага, зато как любят делать сравнения с собаками, типа вот смотри есть объект собака, она гавкает, тявкает, а ещё у неё есть глаза и рот, вот это да, все просто понятно

Только если так делать код, все быстро пойдёт не туда

Ага, зато как любят делать сравнения с собаками, типа вот смотри есть объект собака, она гавкает, тявкает, а ещё у неё есть глаза и рот, вот это да, все просто понятно

нет смысла говорить об одном объекте. Вот если ты говоришь о стае сабак и о том как они между собой взаимодействуют, например одна сабака гафкнула и побежала - это сигнал другим собакам

просто у него него есть такой метод

message passing как pub/sub а не как "дернуть процедуру"

собака гафкнула и ей плевать сколько других сабак услышат - ей важно месседж донести

ей даже не важно среагирует кто или нет, точнее как, может быть важно но это ее проблемы

угу, гавк не означает, что кто - то ответит

хотя думаю пчелы или муравьи намного лучше подходят для этой аналогии

(потому что я не шарю в малекулярной биологии что бы оттуда примеры приводить)))

как там это умное слово - эмердженс или эмергентность (подсмотрел в вики перевод)

собака гафкнула и ей плевать сколько других сабак услышат - ей важно месседж донести

Это на самом деле похоже просто на реактивность)) Просто другой контрол флоу, если ты будешь продолжать мутировать своих собак неконтролируемо, то это не есть хорошо

По сути ты можешь написать такой код: bark(){ this.barked += 1; this.dogsCrew.dispatch(“barked”) } Вот они все начинают лаять и тебе надо отследить как они лаят, ты пишешь дополнительный код чтобы следить за состоянием. Когда если бы у тебя не было внутренного стейта собаки, ты бы переиспользовал какой-нибудь единожды написанный hof withLog

По сути ты можешь написать такой код: bark(){ this.barked += 1; this.dogsCrew.dispatch(“barked”) } Вот они все начинают лаять и тебе надо отследить как они лаят, ты пишешь дополнительный код чтобы следить за состоянием. Когда если бы у тебя не было внутренного стейта собаки, ты бы переиспользовал какой-нибудь единожды написанный hof withLog

dogsCrew лишнее тут. Ты просто гафкаешь

И это как бы пример вообще высосанный из пальца, просто пытаюсь донести что не надо миксовать данные с методами для работы над этими данными. Из того же DDD есть Entity/Value и есть отдельная сущности для работы с ними

bark() { broadcast("bark") }

И это как бы пример вообще высосанный из пальца, просто пытаюсь донести что не надо миксовать данные с методами для работы над этими данными. Из того же DDD есть Entity/Value и есть отдельная сущности для работы с ними

ты про корень агрегата?

или о чем ты?

плохо понимаю твою мысль

Корень агрегата? Это по-английски как? Я про Entity-Value-Repository подход в работе с данными, он же не от хорошей ООП жизни пошёл когда все делали один класс в котором и данные были и persist метод

bark() { broadcast("bark") }

Глобальный броадкаст?

Корень агрегата? Это по-английски как? Я про Entity-Value-Repository подход в работе с данными, он же не от хорошей ООП жизни пошёл когда все делали один класс в котором и данные были и persist метод

aggregate root

ERROR: S client not available

Корень агрегата? Это по-английски как? Я про Entity-Value-Repository подход в работе с данными, он же не от хорошей ООП жизни пошёл когда все делали один класс в котором и данные были и persist метод

репозиторий это тупая коллекция в контексте DDD.

у нее есть add

коллекция агрегатов. Работать с агрегатом можно только через ее корень (information hiding), в рамках одной бизнес транзакции могут быть задействованы несколько агегатов (в разных контекстах)

Ну я не имел это ввиду, это уже дальше от темы

Глобальный броадкаст?

можно глобальный

Ну я не имел это ввиду, это уже дальше от темы

ну вот непонятно что ты имеешь ввиду и что там у тебя не от хорошей жизни

если ты привел репозиторий как "сущность для работы с ними" то ты не прав и репозиторий никак не взаимодействует с тем что он хранит - это коллекция.

что до "не смешивать данные и методы" - а в ФП ты как делаешь? у тебя разве не в рамках модуля описаны типы с которыми могут работать функции? или ты о том что бы удобно добавлять поведение сверху, аля декорация?

если ты привел репозиторий как "сущность для работы с ними" то ты не прав и репозиторий никак не взаимодействует с тем что он хранит - это коллекция.

В этом-то и суть что никак не взаимодействует

что до "не смешивать данные и методы" - а в ФП ты как делаешь? у тебя разве не в рамках модуля описаны типы с которыми могут работать функции? или ты о том что бы удобно добавлять поведение сверху, аля декорация?

В рамках модуля

В этом-то и суть что никак не взаимодействует

а у тебя коллекции взаимодействуют что-ли?)

В рамках модуля

тогда в чем разница?

define "module", кто что под ними понимает

А то в reason такие модули шо вы офигеете

тогда в чем разница?

Добавлять поведение сверху))

Ага, зато как любят делать сравнения с собаками, типа вот смотри есть объект собака, она гавкает, тявкает, а ещё у неё есть глаза и рот, вот это да, все просто понятно

Лучше делать сравнение не что собака делает, а из чего она состоит) Я вижу собаку как композицию органов которые взаимодействуют между собой, органы в свою очередь состоят из тканей, и так дальше до атомов. Но всё это в свою очередь не смешано в одной большой куче, а отделено друг от друга абстракциями. Когда собака ест, к примеру, она мысленно не перемещает кучки атомов, а делает это на высоком уровне абстракции

А то в reason такие модули шо вы офигеете

И в том числе поведение сверху на весь модуль

Это не абстрагирование, это просто изменение масштаба

Добавлять поведение сверху))

кто тебе мешает это делать в ООП?)

ты про модификаторы доступа?)

Лучше делать сравнение не что собака делает, а из чего она состоит) Я вижу собаку как композицию органов которые взаимодействуют между собой, органы в свою очередь состоят из тканей, и так дальше до атомов. Но всё это в свою очередь не смешано в одной большой куче, а отделено друг от друга абстракциями. Когда собака ест, к примеру, она мысленно не перемещает кучки атомов, а делает это на высоком уровне абстракции

нет, это не про ООП

нет, это не про ООП

ну тогда что такое ООП?)

даже information hiding тебе намекает что плевать из чего состоит собака. важно то как она взаимодействует с другими собаками и выполняет ли она какие-то функции

кто тебе мешает это делать в ООП?)

Бойлерплейт который при этом приходится использовать)

Бойлерплейт который при этом приходится использовать)

https://kotlinlang.org/docs/reference/delegation.html

Это как с первым ангуляром, в итоге всё что первый ангуляр изначально давал по факту в проектах больше хеллоу ворлда использовать себе дороже

я к тому что ты сча свел разницу между фп и ооп к синтаксису

Да

Ну я с тобой был согласен