Смысл ООПроектирования чтобы выделить все функции которые работаю именно с этой структурой в единый объект. Сгруппировать их в единую абстракцию и дальше уже на основе нее строить более сложные конструкции. Ток для этого надо проектировать уметь, смотреть шире и иметь возможность к абстрактному мышлению. А вы тут зациклились на определении объекта как Актора.
ЛОЛ, с анемичной моделью это тоже ООП. Просто логика из Классов которые являются структурами данных перенесена в классы отвечающие за эту самую логику. Тобишь Сервисы. Вообще ООП оно про взаимодействие объектов друг с другом так или иначе и в том же Хаскель в прикладном каком нибудь коде так же будут объекты Order, User, Item и взаимодействие их с друг другом через связанные с ними функции.
Вообще да, все что угодно это объект а тайпклассы это способ работы с категориями объектов. Работа со всеми объектами которые можно сравнивать (aka имеют метод eq) например. Тайпклассы это как раз таки ООП часть ФП.
Объект это структура данных и набор функций ака методов для работы с ней. Связанных с ней. Поэтому List и Maybe это объекты.
Те же каррированные функции это объекты и какой нибудь
def add(a)(b)
val c = add(1)
val r = c(2)
будет равен по сути своей вызову у инстанса объекта Int метода add вот так
var r = 1.add(2)
Вообще да в скале 1 реально инстанс объекта и у 1 реально есть метод + и по сути 1 + 2 это в Scala синтаксический сахар над вызовом метода объекта Int. Такие дела.
Что-то не вижу ответа на мой вопрос — ни ниже, ни выше.
Глаза протрите.
состояние торчит наружу
То есть по вашему ООП про приватное состояние и получается что в каком нибудь Python ООП нет? Шире мыслить надо. Objects are poor man's closures ООП оно про то что результат вычисления зависит не только от входных параметров его метода но и от каких-то еще данных и эти данные вполне могут быть публичными. Какой нибудь контроллер который возвращает какое нибудь значение которое ему возвращает какой-то репозиторий которым он обладает это таки типичный объект потому что он возвращает значения на основе данных которые ему отдает его репозиторий (который тоже может обладать стейтом или в просто виде массива или в виде БД) а не только тех данных которые ему передали в качестве параметров.Только вот обычно сам объект идет неким параметром в каждом методе. this или self. Ничего не напоминает? А ну да например >>= первым параметром принимает саму монаду т. е. this aka self. Для любой монады результат do x< — monad return x зависит от того какое значение было до этого в монаде (например если было None то None и вернется) поэтому вообще любая монада это объект. Не несите фигни. А то как в той поговорке, научили грамоте осла раньше он просто глупости говорил а теперь он говорит глупости грамотно. Еще раз для таких как вы повторяю — ООП оно про то что функция или метод связанный с объектом возвращает значение или вызывает эффект на основе текущего состояния этого объект и абсолютно не важно публичное ли это состояние или нет.
И еще накину про упаковку. Вот есть byte[]. byte это структура. Где по вашему будут хранится цифры которые будут добавляться в этот список на стеке или на куче? Будут ли они при этом box?
Вся Scala это ООП + ФП. Да и в хаскеле какая нибудь монада State это такой типичный объект. В Эрланге акторы это вообще эталонное ООП. ФП против Мутабельности. ФП против императивности. ФП вместе с ООП идет в комплекте в большинстве ЯП. Тобишь для ФП главное это иммутабельность и изоляция эффектов за счет вынос их в объекты отложенного выполнения рантаймом.
Попишешь но это будет такой код что поддерживать его да и вообще второй раз в жизни видеть желания у тебя не будет. Хотя и на Rust это все с лайфтаймами делается и с вставками unsafe местами. Няша, лоу латенси на самом деле не то говно с которым хочется иметь дело на постоянной основе. Очень на много компромиссов приходиться идти.
Эм, структуру можно эффективно использовать и пофиг на то что нельзя пререопределить конструктор по умолчанию. Guid и DateTime пример такого использования. Типичные такие ValueObject с заранее известным состоянием по умолчанию.
Про реальную разработку это скорее Scala. Вот где уж библиотеки на все что движется и не движется. Летает плавает и вообще. За счет Java конечно. Хотя в целом свои либы есть у Scala и они мне очень нравятся. http4s, fs2, doobie, tapir прям рекомендую. Они прекрасны по моему. Ну и ScalaTest, ScalaCheck, ScalaMock — либы для тестирования тоже по моему конфетки. В целом можно писать настоящий тырпрайс код что собственно и делают 100+ Scala программистов в Тинькоф.
Я на PHP, JS, Go, Python, Swift (пол года iOS разрабом поработал на работе куда нанимался С# программистом потому что захотелось попробовать и была возможность), JS, TS, Rust и вот недавно Scala и Idris. Таки вообще не сказал бы что JS даже близко рядом С# который на голову его лучше. Примерно на столько на сколько Idris лучше C#. Судя по всему автор совсем выгорел. Яб лучше на что нибудь по сложнее прешел бы с С#. На Scala или Idris там хотя и так сам по себе C# хорош в плане ЯП чтобы «Работу работать».
Эм, замечание от КЭП — там можно выбрать шаблон с Angular. Там выбрать тип аутентификации Individual User Accounts и все. Создастся приложение с авторизацией и Агуляр гуем где можно прям брать и уже забыв про этот весь бойлерплейт писать код нашей бизнес логики. Там сразу будет и авторизация, и регистрация пользователей и все остальное. Буквально пару галочек и пару кликов мышкой.
Пригород Новосибирска. Я сам оттуда. Там просто жилье дешевое. Вы скорее всего тоже можете хоть сейчас там купить такой дом. Только нафига вам дом в Сибири да еще в пригороде?
Была у меня девушка ТопМенеджер. Зарабатывала раза в 3 больше чем я. Ну нафиг. Такое себе. Я люблю когда девушка мне много внимания уделяет а не своей работе.
Те же каррированные функции это объекты и какой нибудь
def add(a)(b)
val c = add(1)
val r = c(2)
будет равен по сути своей вызову у инстанса объекта Int метода add вот так
var r = 1.add(2)
Вообще да в скале 1 реально инстанс объекта и у 1 реально есть метод + и по сути 1 + 2 это в Scala синтаксический сахар над вызовом метода объекта Int. Такие дела.
Глаза протрите.
То есть по вашему ООП про приватное состояние и получается что в каком нибудь Python ООП нет? Шире мыслить надо. Objects are poor man's closures ООП оно про то что результат вычисления зависит не только от входных параметров его метода но и от каких-то еще данных и эти данные вполне могут быть публичными. Какой нибудь контроллер который возвращает какое нибудь значение которое ему возвращает какой-то репозиторий которым он обладает это таки типичный объект потому что он возвращает значения на основе данных которые ему отдает его репозиторий (который тоже может обладать стейтом или в просто виде массива или в виде БД) а не только тех данных которые ему передали в качестве параметров.Только вот обычно сам объект идет неким параметром в каждом методе. this или self. Ничего не напоминает? А ну да например >>= первым параметром принимает саму монаду т. е. this aka self. Для любой монады результат do x< — monad return x зависит от того какое значение было до этого в монаде (например если было None то None и вернется) поэтому вообще любая монада это объект. Не несите фигни. А то как в той поговорке, научили грамоте осла раньше он просто глупости говорил а теперь он говорит глупости грамотно. Еще раз для таких как вы повторяю — ООП оно про то что функция или метод связанный с объектом возвращает значение или вызывает эффект на основе текущего состояния этого объект и абсолютно не важно публичное ли это состояние или нет.