Ну тут уже кидали ссылку на статью объясняющую что любая частично примененная функция ака каррированная, это по сути объект с одни методом. Ну а про то что ООП оно про стейт это вы в самое яблочко. Вся суть ООП это работа со стейтом и везде где надо работать со стейтом начинается в той или иной форме ООП. Да вон фул ФП либа doobie возвращает объект Conection котоырой хранит в себе стейт тех операций с БД что надо сделать. Дальше у него вызываются методы ака он передается функциям в качестве основного параметра и т.д. Да тот же List в Хаскеле это объект такой типичный. Просто вот что стейт обязательно мутабельный этот прям ЛОЛ. Даже в ООП Java тот те паттерн стейт реализуют через возврашение мового стейта. Тобишь вместо того чтобы мутировать текущий просто создают новый с новым стейтом.
Что за фигню вы опять несете? В Хаскеле лист это объект у которого есть стейт — коллекция данных. Который инкапсулирует в себя (внезапно инкапсуялиция она про собирать вместе, включать в себя а сокрытие про то что с наружи не видно. Одно без другого живет) работы с коллекцией данных внезапно. Как какой нибудь HttpClient работы с HTTP инкапсулирует.
Ну TyDD про типы. ООП про экземпляры этих типов. Таки да, ООП лучше со статической типизацией живет. Ну и каждый Объект описывается неким типом. Если вы используете ООП то автоматически начинаете работать с типами. Другое дело что без статической типизации их проверить при компиляции нельзя и TyDD не работает но ваша программа продолжает базироваться на свойствах каких-то типов (классов например).
Я просто много подходов знаю и умею. Как и очень много языков программирования знаю и умею поэтому вижу больше и взгляды у меня более широкие. ООП рука об руку идет с TyDD и с Модульностью и без них сложные прикладные программы хорошими сложно сделать на любом ЯП. Просто в одних Языках это все делается через IRepository, IMovable, IUnitOfWork, User в других через User, Monad, Functor, Movable и т. д. Вся суть ООП про то — какую роль в нашей программе играет инстанс вот этого вот типа. Если вы проектируете и пишете код на основе этого то ООП если нет то не ООП.
Инкапсуляция не значит сокрытие. Массив объектов User является объектом который инкапсулирует в себе несколько объектов User. Для ООП сокрытие в принципе не нужно хотя с ним удобнее.
Эээ, так в динамических ЯП объекты с неким типом идут. в том же JS есть тип number. Так и class User в нем это тип. Динамическая типизация это значит что типы проверяются во время выполнения а не во время компиляции. Динамическая это не значит что типов нет…
Ну и да. class в частности да и объект в общем это какие-то типы поэтому ООП намертво связанно в TyDD (Type Driven Development) Да и в целом суть одна и та же. Если в ООП вы концентрируетесь на том какие объекты у вас есть и что с ними можно сделать то в TyDD вы концентрируетесь на том какие типы у вас есть и что с ними можно сделать. Ну и Процедурное Программирование оно про то какие функции/процедуры у вас есть и что они могут сделать.
Зависит от того как вы строите свой код и разбиваете его на модули. Вокруг этой структуры данных или нет. В том же Swift или Rust у него могут быть методы. Да в Scala у него могут появится методы от тайпклассов. Это взглянув на пару строчек нельзя сказать. Это можно только полностью код посмотрев и оценив как идет логическое разбиение на модули понять. Грубо говоря в той же Java можно сказать что Методы это процедуры которые первым параметром принимают сам объект как this. Анемичная модель вполне себе позволяет писать ООП код. Вообще в том же C# можно через методы расширения к анемичной модели прикрепить методы.
Что за фигню вы несете? Вы либо выделяете в своей системе объекты (User, Item, Money) и вокруг них стоите свою систему либо нет. Вот и весь смыл. Вам просто надо перестать смотреть на объекты как на классы из Java ( я вообще нигде не говорил классы а говорил объекты почему вы пытаетесь общую концепцию объекта сузить до класса из Java?) и понять что это более общая абстракция которая по сути значит инстансы неких типов данных. И да, любую структуру данных можно представить как объект. И обратное тоже верно. Можно любую структуру данных рассматривать как просто данные для вашей функции. 1 это и объект тип Int и одновременно не объект. Все зависит от того на основе какого предположения вы будете проектировать и писать свой код.
Допустим у вас ЯП без генериков и кодо генерации. Вам нужно сделать метода добавления и умножения для Int и для Float.
В ООП стиле — вы сделаете модуль где будут методы Add и Mul для Int Потом сделает отдельный модуль где будут методы Add и Mull для Float
Без ООП стиля — вы сделаете модуль где будут все Методы Add и модуль где будут все методы Mul. Потому что вам важнее что за функции у вас есть и что они делают. В ООП наоборот для вас важнее что за структуры данных у вас есть и что с ними можно сделать. Теперь разницу поняли?
Мысль вам на размышление. Класс Java или C# который содержит методы которые не используют данные самого этого класса тоже не являться объектом. Просто неймспейс ака модуль для набора функций/процедур
//Это не объект хоть и класс C#
class Calculator
{
int Add(int a, int b) => a + b
}
//Вот это объект
class Service
{
public IRepository Repo{get;set;}
public int Count() => Repository.Count()
}
Еще раз — зависит от того как вы о них думает. Объект это логическая единица. ООП он про проектирование. Вы слишком узко мыслите со своим представлением об Объектах из Java. В паре строчек кода не увидеть занимался ли человек ООП. Надо глобально смотреть как у него построена система. Вокруг объектов или просто разрозненные структуры данных и фукнции. Класс в Java это модуль и там ООП по сути сводится к умению разделять правильно код на модули и это умение одинаково полезно в любом ЯП и одинаково редко встречается везде.
Особенно какие нибудь тайпкласс Movable и Damageble сразу становится понятно что они про какой-то объект который умеет двигаться и может получать урон.
Так для справки Мутабельность противоречит Иммутабельности. Декларативность противоречит Процедурности. ООП код не противоречит ФП поэтому его сложно как-то особо отличить. Вы этого не понимаете поэтому думаете что есть какие-то четкие различия а на самом деле код может быть и ФП и ООП одновременно.
Ну и тайклассы это прям натуральная ООП фишка потому что они этим самым связыванием и группировкой экземпляров неких типов с некими функциями (методами) занимаются. В Хаскеле синтаксис ML но в Scala натурально как методы вызываются функции тайпклассов вроде
list.map(x=>x+1)
Объект это экземпляр какого-то типа и связанные с ним методы использующие данные этого конкретного экземпляра. Это больше логическая единица моделирующая что-то на текущем уровне абстракции. ООП оно больше про проектирование чем про сам код. В том же Swift у вас могут быть методы объекта отдельно от него. Да и в Rust тоже. Оно больше про то как вы о своем коде думаете.
Например
val x = 1
val notOopX = mul(add(x,2),3)
val oopX = x.add(2).mul(3)
Разница тут в вызвать у объекта X метод или вызвать функцию add с передачей ей x в качестве параметра. То бишь оба вариант могу быть ООП если для вас важнее какие у меня есть X и что он может сделать чем какие у меня есть функции и что они могут сделать.
На самом деле это нужно только в сложных прикладных приложениях с огромным количеством разных структур данных. Вроде игр. Только такие вещи на ФП языках обычно не пишут.
Смысл ООПроектирования чтобы выделить все функции которые работаю именно с этой структурой в единый объект. Сгруппировать их в единую абстракцию и дальше уже на основе нее строить более сложные конструкции. Ток для этого надо проектировать уметь, смотреть шире и иметь возможность к абстрактному мышлению. А вы тут зациклились на определении объекта как Актора.
Допустим у вас ЯП без генериков и кодо генерации. Вам нужно сделать метода добавления и умножения для Int и для Float.
В ООП стиле — вы сделаете модуль где будут методы Add и Mul для Int Потом сделает отдельный модуль где будут методы Add и Mull для Float
Без ООП стиля — вы сделаете модуль где будут все Методы Add и модуль где будут все методы Mul. Потому что вам важнее что за функции у вас есть и что они делают. В ООП наоборот для вас важнее что за структуры данных у вас есть и что с ними можно сделать. Теперь разницу поняли?
list.map(x=>x+1)
Например
Разница тут в вызвать у объекта X метод или вызвать функцию add с передачей ей x в качестве параметра. То бишь оба вариант могу быть ООП если для вас важнее какие у меня есть X и что он может сделать чем какие у меня есть функции и что они могут сделать.