пример в студию

как бы родитель - должен хранить только то что нужно его детям

но дети всегда разные

ты не учтешь все и вся, а если учтешь, внедрить любую мелочь как изменение - ад

Слушай, а ты сейчас на каком языке пишешь в прод?

наследование без соплей: фп

можно заканчивать диалог

ты не учтешь все и вся, а если учтешь, внедрить любую мелочь как изменение - ад

Напротив, в ООП с SOLID никаких проблем нет

Слушай, а ты сейчас на каком языке пишешь в прод?

питон, хаскель внедряю

питон, хаскель внедряю

В питоне чисто функционально пишешь?

На том же хаскелле все куда сложнее

Напротив, в ООП с SOLID никаких проблем нет

открой любой крупный ява проект например, и разверни конечный класс взад, там под десяток другой родителей

и попробуй легко поменять, муаххаа

На том же хаскелле все куда сложнее

если писать в стиле ооп то конечно да

Унаследовал, поменял

В питоне чисто функционально пишешь?

стараюсь по мере его возможностей и они слабые

стараюсь по мере его возможностей и они слабые

Чего там не хватает?

Унаследовал, поменял

поменял ту часть что пришла от родителя?

поменял ту часть что пришла от родителя?

Да.

он сейчас скажет что овверайдинг - костыль

Конечно

три.два.один

Да.

и классы которые ожидают от детей тоже поведение что у родителя встали раком

он сейчас скажет что овверайдинг - костыль

а разве нет?

целостность потерялась

Если вам нужно поменять поведение интерфейса, вы что-то делаете не так

Если вам нужно поменять поведение интерфейса, вы что-то делаете не так

какие ещё интерфейсы

и классы которые ожидают от детей тоже поведение что у родителя встали раком

ну так бездумно везде применять наследование это как весь код в IO заворачивать в Хаскелле

это же придётся плодить абстракции

ты что

Если вам нужно поменять поведение интерфейса, вы что-то делаете не так

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

это же придётся плодить абстракции

вот именно и это тоже

Соглашение интерфейса важнее ваших костылей

ну так бездумно везде применять наследование это как весь код в IO заворачивать в Хаскелле

почти все в ооп это костыли обхода зависимостей

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

Т.е. функциональщина - полная анархия? Или всё таки какого-то стиля придерживаться надо?

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

а в хаскелле ты свободно можешь поменять определение типа?

В фп вы точно так же не можете менять логику функций

Соглашение интерфейса важнее ваших костылей

интерфейсы еще больше путаницы вносят

Это бред

В фп вы точно так же не можете менять логику функций

можешь, меняй

какую путанницу вносят интерфейсы?

а в хаскелле ты свободно можешь поменять определение типа?

тип это не класс

можешь, меняй

и всех caller'ов тоже

можешь, меняй

тоже самое могу сказать про любой ооп яп

тип это не класс

и?

интерфейсы еще больше путаницы вносят

Охлол, в тайпклассы - не интерфейс?

и?

иметь много типов норма иметь много классов не норма

иметь много типов норма иметь много классов не норма

Почему?

иметь много типов норма иметь много классов не норма

иметь много типов не норма иметь много классов норма

не, все же круто товарищ вас троллит )

Почему иметь много классов - не норма?

мне интересно, он рофлит или серьёзно?

Почему?

потомучто типы не связываются потом в дерево, а классы связываются

не, все же круто товарищ вас троллит )

тоже вот начал задумываться этим

потомучто типы не связываются потом в дерево, а классы связываются

Не связывай классы, кто мешает?

Alex, твои аргументы невалидны, потому что в них всегда можно поменять ооп и фп местами и смысл не поменяется

Не связывай классы, кто мешает?

тогда что остается от классов?

тоже вот начал задумываться этим

ну я просто не верю что вменямый человек может так яростно топить за фп и еще такими аргументами мощными

я думаю такие существуют

Alex, твои аргументы невалидны, потому что в них всегда можно поменять ооп и фп местами и смысл не поменяется

нет :) посмотри проект, дерево ооп на хаскеле

вот наглядный пример

отличия фп от ооп и почему нельзя на фп писать в стиле ооп

тогда что остается от классов?

То что и было. Тебя никто не заставляет связывать все классы.

То что и было. Тебя никто не заставляет связывать все классы.

не связанные классы это не ооп

отличия фп от ооп и почему нельзя на фп писать в стиле ооп

потому что это разные парадигмы - думаю по этой причине

нет :) посмотри проект, дерево ооп на хаскеле

а есть какие-то объективные метрики, показывающие превосходство фп над ооп, а не голословные утверждения?

потому что это разные парадигмы - думаю по этой причине

верно

а есть какие-то объективные метрики, показывающие превосходство фп над ооп, а не голословные утверждения?

ну че ты начинаешь, нормально же общались =р

не связанные классы это не ооп

Почему? Мы не создаём объекты?

а есть какие-то объективные метрики, показывающие превосходство фп над ооп, а не голословные утверждения?

сам принцип, описание действий а не дерево-действий-данных

фп это теги ооп это дерево

каково отличие?

сам принцип, описание действий а не дерево-действий-данных

у тебя там чистые действия без данных?

фп это теги ооп это дерево

Понятно, ты считаешь, что ООП - это только дерево. Соглашусь, не всегда вот такое понимание подходит под задачу.

фп это теги ооп это дерево

фп - тоже дерево, просто вызовов, а не объектов

у тебя там чистые действия без данных?

есть но свободно связаные

фп - тоже дерево, просто вызовов, а не объектов

дерево в котором ты легко перекомбинируешь все

в ооп это куча работы

есть но свободно связаные

"свободно связаные" - пойду, повешу в рамку

дерево в котором ты легко перекомбинируешь все

"легко" - голословненько

в ооп это куча работы

тоже голословно

возьми пример, класс автомобиль подкласс водитель подкласс маршрут а теперь отрефактори зеркально в фп это очень просто в ооп это ад

водитель подкласс автомобиля?

возьми пример, класс автомобиль подкласс водитель подкласс маршрут а теперь отрефактори зеркально в фп это очень просто в ооп это ад

Отрефактори зеркально? И что должно получиться?

А, понял. ФП - это сделай через задницу, верно?

водитель подкласс автомобиля?

car = new Car() car->addDriver(new Driver)

верно ли что на haskell можно быстрее и безбажнее чем на C++/java писать небольшие, хорошо формализованные задачи?

car = new Car() car->addDriver(new Driver)

или наследование

Почему? Мы не создаём объекты?

Потому что ООП - это наследование, инкапсуляция и полиморфизм.

верно ли что на haskell можно быстрее и безбажнее чем на C++/java писать небольшие, хорошо формализованные задачи?

безусловно

безусловно

а давай проверим?

Потому что ООП - это наследование, инкапсуляция и полиморфизм.

именно

а давай проверим?

давай

car = new Car() car->addDriver(new Driver)

А до этого ты что хотел сделать?

Отрефактори зеркально? И что должно получиться?

вопрос в легкости изменений

А, понял. ФП - это сделай через задницу, верно?

в фп это делай свободно и рефактори свободно

в этом принципиальное отличие

Потому что ООП - это наследование, инкапсуляция и полиморфизм.

Ну ок, наследуйся от интерфейсов. Никаких проблем нет.

А до этого ты что хотел сделать?

а теперь я хочу легко изменить на Driver->addCar

Ну ок, наследуйся от интерфейсов. Никаких проблем нет.

А потом?