Представление объекта в программировании.
есть паттерн проектирования который так и называется - состояние
есть паттерн наблюдатель
есть паттерн велосипед. самый любимый паттерн петера.в C# и в Delphi есть свойства https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/properties
да и евенты давно не диковинка
но, по моему, очередной топик на слова, довольно неплохой песни "Фея" - ЯжеВика .... Идите вы, а я фея!....
Петр, заход не с той стороны опять. Почему состояние должно быть инструментом? Состояние было и есть, никуда не девалось, оно даже первичней всего остального. И да - событие это не состояние, поэтому оно не описывается, а регистрируется.
Реter Konow:
... а где "официально зарегестрированная" философская концепция Объекта? Увы, таковой не существует по сей день, и быть не может. ...
Потому что оно вообще на философию не опирается. Объект в программировании это не что-то там возвышенное, мистическое или еще что-то, что вы могли себе придумать. Это просто объединение функций и переменных.
Эта тема будет интересна тем, кого занимают глобальные вопросы программирования.
Меня мучает вопрос: "а почему общеизвестная модель Объекта в стандартной концепции ООП является каноном?".
Потому, что первыми идут две больших буквы О. Раз концепция ориентирована на объекты, они и есть главная суть концепции. Точно так же, как и в концепции процедурного программирования главной сутью являются процедуры, в SQL сутью являются запросы с игнорированием способа их исполнения, и проч. и проч. Сутью, а не каноном. Канонизацией именно ООП с противопоставлением его другим подходам активно занимаются на этом форуме, поэтому и складывается такое впечатление.
Вместо изобретения самопальных велосипедов стоит изучить теорию типов и попрактиковаться в её применении при программировании на функциональных языках (например, хаскель).
Для понимания философских и логических основ можно читать Бертрана Рассела.
Эта тема будет интересна тем, кого занимают глобальные вопросы программирования.
Бла бла бла.
Всё это не имеет отношения ни к ООП ни к программированию.
Лучше назовите тему: "Сколько объектов поместится на кончике иглы?"
Потому, что первыми идут две больших буквы О. Раз концепция ориентирована на объекты, они и есть главная суть концепции. Точно так же, как и в концепции процедурного программирования главной сутью являются процедуры, в SQL сутью являются запросы с игнорированием способа их исполнения, и проч. и проч. Сутью, а не каноном. Канонизацией именно ООП с противопоставлением его другим подходам активно занимаются на этом форуме, поэтому и складывается такое впечатление.
Потому что оно вообще на философию не опирается. Объект в программировании это не что-то там возвышенное, мистическое или еще что-то, что вы могли себе придумать. Это просто объединение функций и переменных.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Эта тема будет интересна тем, кого занимают глобальные вопросы программирования.
Меня мучает вопрос: "а почему общеизвестная модель Объекта в стандартной концепции ООП является каноном?". В смысле, Объект - сущность, которую люди описывают словами каждый раз произнося слово. С появлением программирования, логично связана попытка описания Объекта кодом, для чего придумана спец. технология, но вот вопрос: а, почему только одна? Как, если бы первый язык полностью вытеснил остальные и не дал им развиться. Это невозможно в древние времена, но возможно в эпоху глобализма и пропаганды. Так и случилось - одно представление Объекта завоевало мир и перекрыло направления других идей.
Я бы давно принял стандартную концепцию Объекта, если бы у меня (как у философа) не возникли к ней претензии.
Это означает, что авторы концепции ООП действовали произвольно, опираясь на "непогрешимость" своих философских представлений.
2. Вот, некоторые из моих претензий:
(1) Почему в стандартной концепции нет инструмента " состояние"? Разве объекты не обладают состояниями? Состояние можно описать в структуре, но это неудобно. Стандартная концепция не заточена на работу с состояниями объектов. Например: создаю спец. структуру, перечисляю параметры объекта, копирую ее часть (выбранные параметры), именую, определяю эту часть как состояние и пишу значения, которые соответствуют некому состоянию объекта. Потом связываю с основной структурой объекта.
(2) Нет инструмента "событие". В смысле, Событие "витает" в стандартной концепции, но его нельзя описать как перечисление, класс или функцию. Простое описание события в программировании очень бы пригодилось. Например: описываем его как структуру, но в ней указываем на "фоновые" состояния окружения и объектов, и указываем на ключевое изменение, которое и есть тригер начала цепочки других изменений. Опять же - ООП не заточено на сжатое описание события и предлагает описывать их в куче условий, которые не имеют наименования и распологаются "где попало".
(3) Далее, параметр не представляет из себя самостоятельный объект. На самом деле - это наиважнейший объект, которые можно шаблонизировать и собирать из его копий и модификаций любые системы. Этого нет...
Можно еще много перечислять, но мой посыл и так понятен: лепите свой ООП и возможно, изобретете что то покруче, ведь никто до вас серьезно не пытался. А стантдартная концепция - субъективное видение, а не физика или математика и его можно модифицировать.))