Объект это экземпляр какого-то типа и связанные с ним методы использующие данные этого конкретного экземпляра.
int x = 1; int y = 2; int z = x + y;
x, y, z — это объекты? Код(java) объектно-ориентирован?(вопрос в том, что даже в терминологии Java ничего из объявленного — не объект).
А для того же кода на haskell — x, y, z это объекты? Код объектно ориентирован?
x = 1 :: Int
y = 2 :: Int
z = x + y
На мой взгляд Ваше определение термина «объект» имеет место в целом в computer science, но никакого отношения к термину «объект» объектно-ориентированного программирования не имеет(во всяком случае это разные вещи).
Само определение объекта ООП таким образом, просто обесценивает ООП, ведь по сути нельзя написать не объектно-ориентированный код — в чём тогда ценность термина?
Вообще ООП оно про взаимодействие объектов друг с другом так или иначе и в том же Хаскель в прикладном каком нибудь коде так же будут объекты Order, User, Item и взаимодействие их с друг другом через связанные с ними функции
То, что всё объект и везде ООП, Вы уже объяснили. Пойдём от обратного — возможно ли писать не объектно ориентированный код? Можно пример такого кода?
показывают хороший код и плохой. Когда показывают плохой код — бьют током. Так у программиста вырабатывается условный рефлекс, и он больше не пишет плохой код.
да, но функция, грубо говоря, будет просто работать с монадическим интерфейсом. Т.е. различным образом соединять монадические комбинаторы, зацикливать вычисления и т.д.
Но вот сегодня не делать ничего, а завтра полезть в файл она не сможет.
Тайпклассы просто механизм, который способен выступить аналогом диспатчера сообщений(виртуальных методов) в ООП языках. Т.е. они позволяют добиться аналогичного эффекта, но это не делает всё, что использует тайпклассы, объектно ориентированным. Даже на ООП языках можно писать не объектно ориентированно(возьмите ту же анемичную модель).
Объект это структура данных и набор функций ака методов для работы с ней. Связанных с ней. Поэтому List и Maybe это объекты.
А вас не смущает, что для любой структуры данных есть функции, которые с ней работают? Если всё ООП, то нет никакого ООП, т.к. нет смысла отдельно упоминать о том, что есть везде и по умолчанию.
То есть по вашему ООП про приватное состояние и получается что в каком нибудь Python ООП нет? Шире мыслить надо.
Это был один из критериев, вы путаете инкапсуляцию и сокрытие. Далее был описан пример data-bean, в котором есть сокрытие, но нет инкапсуляции.
ООП оно про то что результат вычисления зависит не только от входных параметров его метода но и от каких-то еще данных и эти данные вполне могут быть публичными
Опять же — Вы путаете ООП и процедурное программирование, ООП совсем не про это.
ООП про объекты, их поведение и взаимодействие(сообщения), про инкапсуляцию внутреннего состояния.
Только вот обычно сам объект идет неким параметром в каждом методе. this или self. Ничего не напоминает? А ну да например >>= первым параметром принимает саму монаду т. е. this aka self. Для любой монады результат do x< — monad return x зависит от того какое значение было до этого в монаде (например если было None то None и вернется) поэтому вообще любая монада это объект.
Да чего мелочиться то? f x = x зависит от того какое значение было до этого в x (например если было None то None и вернется) поэтому вообще всё что угодно это объект. А если назвать x 'this', то и комар носа не подточит. f this = this. Матерь божья, где-то я это уже видел:
Геттеры и сеттеры выступают в роли сообщений, которые принимает data-bean, так он становится подобным объекту.
Но объект это только формально, по факту data-bean не управляет своим состоянием, а, значит, объектом не является. Это просто структура, мимикрирующая под объект.
Что-то не вижу ответа на мой вопрос — ни ниже, ни выше.
Мне просто интересно, почему по вашему монада State это не объект?
состояние торчит наружу, объекты имеют внутреннее состояние. Разные объекты могут взаимодействовать друг с другом путём отправки сообщений, обрабатывать сообщения. В Java, например, этот механизм редуцирован до (subtype)полиморфных методов. State же подобных механизмов не имеет.
И да, это не значит что ООП на hs нельзя изобразить, вполне себе можно. Только, как и везде(в т.ч. Java), это очень редко нужно.
А ООП без классов это просто процедурное программирование. Значит ФП это просто процедурное программирование.
Вывод: то что действительно важно — это классы(если грубо округлить).
если говорить о haskell, то с точки зрения языка — всё чистое, даже IO. Собственно, IO и нужна как-раз для того что-бы «чистым» образом описать «грязный» ввод-вывод.
Делегировать простому объекту контейнеру знание о бизнес логике не самая здравая идея
а по-моему Вы что-то путаете. Где Вы видели в каком-либо определении понятия ООП термин «бизнес логика»? С точки зрения ООП код pin2t вполне себе каноничный.
С других точек зрения — да, есть к чему придраться.
А Math это вообще не ООП ни разу. Это просто набор функций.
x, y, z — это объекты? Код(java) объектно-ориентирован?(вопрос в том, что даже в терминологии Java ничего из объявленного — не объект).
А для того же кода на haskell — x, y, z это объекты? Код объектно ориентирован?
На мой взгляд Ваше определение термина «объект» имеет место в целом в computer science, но никакого отношения к термину «объект» объектно-ориентированного программирования не имеет(во всяком случае это разные вещи).
Само определение объекта ООП таким образом, просто обесценивает ООП, ведь по сути нельзя написать не объектно-ориентированный код — в чём тогда ценность термина?
Но вот сегодня не делать ничего, а завтра полезть в файл она не сможет.
Это был один из критериев, вы путаете инкапсуляцию и сокрытие. Далее был описан пример data-bean, в котором есть сокрытие, но нет инкапсуляции.
Опять же — Вы путаете ООП и процедурное программирование, ООП совсем не про это.
ООП про объекты, их поведение и взаимодействие(сообщения), про инкапсуляцию внутреннего состояния.
Да чего мелочиться то? f x = x зависит от того какое значение было до этого в x (например если было None то None и вернется) поэтому вообще всё что угодно это объект. А если назвать x 'this', то и комар носа не подточит. f this = this. Матерь божья, где-то я это уже видел:
Но объект это только формально, по факту data-bean не управляет своим состоянием, а, значит, объектом не является. Это просто структура, мимикрирующая под объект.
Что-то не вижу ответа на мой вопрос — ни ниже, ни выше.состояние торчит наружу, объекты имеют внутреннее состояние. Разные объекты могут взаимодействовать друг с другом путём отправки сообщений, обрабатывать сообщения. В Java, например, этот механизм редуцирован до (subtype)полиморфных методов. State же подобных механизмов не имеет.
И да, это не значит что ООП на hs нельзя изобразить, вполне себе можно. Только, как и везде(в т.ч. Java), это очень редко нужно.
P.S. а вывод «ФП это просто процедурное программирование» вас не смущает? Это как сказать чёрное это белое…
Вывод: то что действительно важно — это классы(если грубо округлить).
Это называется "переменная ссылочного типа".
С других точек зрения — да, есть к чему придраться.
А Math это вообще не ООП ни разу. Это просто набор функций.