Представление объекта в программировании.

 

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

Меня мучает вопрос: "а почему общеизвестная модель Объекта в стандартной концепции ООП является каноном?".  В смысле, Объект - сущность, которую люди описывают словами каждый раз произнося слово. С появлением программирования, логично связана попытка описания Объекта кодом, для чего придумана спец. технология, но вот вопрос: а, почему только одна?  Как, если бы первый язык полностью вытеснил остальные и не дал им развиться. Это невозможно в древние времена, но возможно в эпоху глобализма и пропаганды. Так и случилось - одно представление Объекта завоевало мир и перекрыло направления других идей.

Я бы давно принял стандартную концепцию Объекта, если бы у меня (как у философа) не возникли к ней претензии.

  1. Сначала предисловие: Эволюционный шаг в программировании был сделан когда утвердили главный тезис - программирование берет за основу "объекты" и любая программа должна логически на них разбиваться. То есть - мы больше не пишем алгоритмы (последовательности операций), а создаем "сущности". Алгоритмы же, мы поместим в их структуру, чтобы они стали частью общего "ансамбля" взаимодействия. Почему? - так эффективнее работать. НО, вот вопрос: а где "официально зарегестрированная" философская концепция Объекта?  Увы, таковой не существует по сей день, и быть не может. 

        Это означает, что авторы концепции ООП действовали произвольно, опираясь на "непогрешимость" своих философских представлений.

   2. Вот, некоторые из моих претензий:

   (1) Почему в стандартной концепции нет инструмента " состояние"? Разве объекты не обладают состояниями? Состояние можно описать в структуре, но это неудобно. Стандартная концепция не заточена на работу с состояниями объектов. Например: создаю спец. структуру, перечисляю параметры объекта, копирую ее часть (выбранные параметры), именую, определяю эту часть как состояние и пишу значения, которые соответствуют некому состоянию объекта. Потом связываю с основной структурой объекта.

   (2) Нет инструмента "событие". В смысле, Событие "витает" в стандартной концепции, но его нельзя описать как перечисление, класс или функцию. Простое описание события в программировании очень бы пригодилось. Например: описываем его как структуру, но в ней указываем на "фоновые" состояния окружения и объектов, и указываем на ключевое изменение, которое и есть тригер начала цепочки других изменений. Опять же - ООП не заточено на сжатое описание события и предлагает описывать их в куче условий, которые не имеют наименования и распологаются "где попало".

   (3) Далее, параметр не представляет из себя самостоятельный объект. На самом деле - это наиважнейший объект, которые можно шаблонизировать и собирать из его копий и модификаций любые системы. Этого нет...

Можно еще много перечислять, но мой посыл и так понятен: лепите свой ООП и возможно, изобретете что то покруче, ведь никто до вас серьезно не пытался. А стантдартная концепция - субъективное видение, а не физика или математика и его можно модифицировать.))

        

Документация по MQL5: Константы, перечисления и структуры / Состояние окружения
Документация по MQL5: Константы, перечисления и структуры / Состояние окружения
  • www.mql5.com
Константы, перечисления и структуры / Состояние окружения - справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
 

есть паттерн проектирования который так и называется - состояние

есть паттерн наблюдатель

есть паттерн велосипед. самый любимый паттерн петера.
 

в C# и в Delphi есть свойства https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/properties

да и евенты давно не диковинка

но, по моему, очередной топик на слова, довольно неплохой песни "Фея" - ЯжеВика .... Идите вы, а я фея!....

 
Вообще определяя Объект нужно определить и Субъект, иначе это неполное описание мира, кроме того в более современных философских концепциях есть Траект с самостоятельным отнологическим статусом как промежуточное/связывающее звено между Объектом и Субъектом.
 

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

 

Реter Konow:

... а где "официально зарегестрированная" философская концепция Объекта?  Увы, таковой не существует по сей день, и быть не может. ...

        

Потому что оно вообще на философию не опирается. Объект в программировании это не что-то там возвышенное, мистическое или еще что-то, что вы могли себе придумать. Это просто объединение функций и переменных.

 
Реter Konow:

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

Меня мучает вопрос: "а почему общеизвестная модель Объекта в стандартной концепции ООП является каноном?".

Потому, что первыми идут две больших буквы О. Раз концепция ориентирована на объекты, они и есть главная суть концепции. Точно так же, как и в концепции процедурного программирования главной сутью являются процедуры, в SQL сутью являются запросы с игнорированием способа их исполнения, и проч. и проч. Сутью, а не каноном. Канонизацией именно ООП с противопоставлением его другим подходам активно занимаются на этом форуме, поэтому и складывается такое впечатление.

 

Вместо изобретения самопальных велосипедов стоит изучить теорию типов и попрактиковаться в её применении при программировании на функциональных языках (например, хаскель).

Для понимания философских и логических основ можно читать Бертрана Рассела.

 
Реter Konow:

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

Бла бла бла.        

Всё это не имеет отношения ни к ООП ни к программированию.

Лучше назовите тему: "Сколько объектов поместится на кончике иглы?"

 
Vladimir:

Потому, что первыми идут две больших буквы О. Раз концепция ориентирована на объекты, они и есть главная суть концепции. Точно так же, как и в концепции процедурного программирования главной сутью являются процедуры, в SQL сутью являются запросы с игнорированием способа их исполнения, и проч. и проч. Сутью, а не каноном. Канонизацией именно ООП с противопоставлением его другим подходам активно занимаются на этом форуме, поэтому и складывается такое впечатление.

Я ведь задал вопрос: "почему стандарт описания и построения обьектов один?". 
Вы решили, что мой вопрос "почему ООП канон?". 
Обьектная ориентированность в программировании структурирует, масштабирует и реализует задачи. К ней вопросов нет. Но, почему формат один? 
 
Dmitry Fedoseev:

Потому что оно вообще на философию не опирается. Объект в программировании это не что-то там возвышенное, мистическое или еще что-то, что вы могли себе придумать. Это просто объединение функций и переменных.

Вот тут никак без философской концепции обойтись нельзя. Просто обьединять функции и переменные не следуя продуманному "чертежу" Обьекта? Нам даны определенные инструменты: классы, структуры, модификаторы доступа... но, могут быть и другие инструменты... например состояние, выборка, связка... почему нет? Я к тому, что формат и инструментарий ООП может иметь версии... 
И в определенных случаях, иная версия формата описания обьекта может быть эффективней.