p
По определению объект имеет внутренне состояние
Size: a a a
2020 May 13
AZ
Object-oriented programming (OOP) is a computer programming model that organizes software design around data, or objects, rather than functions and logic. An object can be defined as a data field that has unique attributes and behavior.
r
Ещё бы общепринятое определение ООП найти.
r
Object-oriented programming (OOP) is a computer programming model that organizes software design around data, or objects, rather than functions and logic. An object can be defined as a data field that has unique attributes and behavior.
То есть объединение data и behavior. Что такое behavior оставлено на усмотрение читателю.
NL
red75prime
То есть объединение data и behavior. Что такое behavior оставлено на усмотрение читателю.
Там можно формализовать дойдя до машины Тьюринга, только это не нужно никому...
Но если посмотреть все реализации объектов в разных языках, то у всех них есть общая черта, что состояние мутабельное неверсионированное и функции, преобразующие одно состояние в другое примотаны к нему изолентой.
Но если посмотреть все реализации объектов в разных языках, то у всех них есть общая черта, что состояние мутабельное неверсионированное и функции, преобразующие одно состояние в другое примотаны к нему изолентой.
NL
Как всегда мутабельное состояние можно заменить бесконечным неизменяемым списком пар (версия, состояние), но "указатель" на последнюю версию состояния всё равно мутабельный.
NL
Объект характеризуется наличием *изменяемого состояния*, и абстрактным интерфейсом доступа, т.е. состояние "спрятано".
Казалось бы никто не мешает делать объекты иммутабельными, мутирующие функции просто будут возвращать новые объекты (как со строками в .NET/Java).
Но на деле это очень мешает. Скептики могут попробовать на таких объектах построить систему, увидят. На таких "объектах" вы не получите главного — не сможете сделать декомпозицию системы.
Просто попробуйте, это проще, чем объяснить. Сделайте систему с кольцевой ссылкой, и посмотрите.
Казалось бы никто не мешает делать объекты иммутабельными, мутирующие функции просто будут возвращать новые объекты (как со строками в .NET/Java).
Но на деле это очень мешает. Скептики могут попробовать на таких объектах построить систему, увидят. На таких "объектах" вы не получите главного — не сможете сделать декомпозицию системы.
Просто попробуйте, это проще, чем объяснить. Сделайте систему с кольцевой ссылкой, и посмотрите.
VS
Т-34 85
Я не говорил, что это одно и тоже. Я сказал, что ооп без императивщины невозможно. Окей, не невозможно, а лично я не знаю, как это
Ну я могу наверно в Хаскеле сделать тайп классы Movable и Collaidable ну и функции у ним Move, Collide. Ну и функции геттер. Потом реализовать это на конкретных данных - вот тебе и множественное наследование и какие-то типы вроде Tank, Car это объекты. ИМХО можно в ООП стиле и в Хаскель писать. Былоб желание.
VS
в общем всё как всегда) Ты напридумывал своих искусственных огграничений, и теперь сам на них ориентируешься. Ну удачи
+
VS
объект в ООП это сущность имеющая состояние. с объектом общение происходит путем пересылки сообщений. данные внутри объекта максимально сокрыты от окружающего мира.
Чувак, ты серьезно? Чуть более чем всегда в C# торчит публичный геттер на любую фигню. Ну всякие state и strategi обычно если они инжектнутые таки остаются скрытием и всё
OA
>блокчейны не нужны
zkvm🤔
zkvm🤔
Тут есть несколько адекватных юзкейсов, без айсио, стейкинга и недомайнинга
OA
Чувак, ты серьезно? Чуть более чем всегда в C# торчит публичный геттер на любую фигню. Ну всякие state и strategi обычно если они инжектнутые таки остаются скрытием и всё
Если у тебя везде открытые стракты, то виноват не молоток, а плотник
VS
Если у тебя везде открытые стракты, то виноват не молоток, а плотник
Не неси фигню
G
Не неси фигню
Если на каждую фигню геттеры/сеттеры, зачем? Почему бы не обманывать себя мнимой политикой доступа и просто сделать поля публичными?
VS
Если на каждую фигню геттеры/сеттеры, зачем? Почему бы не обманывать себя мнимой политикой доступа и просто сделать поля публичными?
Сеттеры приватные
G
Зачем вообще сеттеры тогда нужны?
VS
Зачем вообще сеттеры тогда нужны?
Разграничение уровней доступа. Хотя иногда только геттер и просто приватное поле пишу. Смотря как удобней и быстрее
G
Разграничение уровней доступа. Хотя иногда только геттер и просто приватное поле пишу. Смотря как удобней и быстрее
А, забыл, в C# же синтаксис геттеров/сеттеров
p
Если на каждую фигню геттеры/сеттеры, зачем? Почему бы не обманывать себя мнимой политикой доступа и просто сделать поля публичными?
Foo { get; private set; }
VS
Зачем вообще сеттеры тогда нужны?
Так тебе нужно и поле и геттер написать а так ты только Свойство написал с приватным сеттером и все. Проще и быстрее и меньше кода.