Representación de un objeto en la programación.

Реter Konow  

Este tema será de interés para quienes se preocupan por las cuestiones de programación global.

La pregunta que me ronda es "¿por qué el conocido modelo de objetos está en el canon del concepto estándar de POO?"Un objeto es una entidad que la gente describe con palabras cada vez que dice la palabra. Con el advenimiento de la programación, el intento de describir el Objeto por medio de un código estaba lógicamente conectado y se inventó una tecnología especial para hacerlo, pero aquí está la pregunta: ¿por qué sólo uno? Como si la primera lengua sustituyera completamente a las demás y no las dejara evolucionar. Esto es imposible en la antigüedad, pero posible en la era del globalismo y la propaganda. Y así sucedió: una representación del Objeto conquistó el mundo y bloqueó las direcciones de otras ideas.

Habría aceptado la concepción estándar del Objeto hace mucho tiempo, si (como filósofo) no hubiera tenido algunas quejas al respecto.

  1. En primer lugar, un prefacio: se dio un paso evolutivo en la programación cuando se expuso la tesis principal: la programación toma como base los "objetos" y cualquier programa debe dividirse lógicamente en ellos. Es decir, ya no escribimos algoritmos (secuencias de operaciones), sino que creamos "entidades". Los algoritmos, en cambio, los estructuramos para que formen parte de un "conjunto" global de interacciones. ¿Por qué? - Así es más eficiente. PERO, aquí está la pregunta: ¿dónde está el concepto filosófico "oficialmente registrado" del Objeto? Desgraciadamente, a día de hoy no existe ninguna, ni puede existir.

Esto significa que los autores del concepto OOP actuaron arbitrariamente, confiando en la "infalibilidad" de sus nociones filosóficas.

2. Aquí están algunas de mis reclamaciones:

(1) ¿Por qué el concepto estándar no tiene una herramienta " El estado de"? ¿Los objetos no tienen estados? Un estado puede describirse en una estructura, pero esto es inconveniente. El concepto estándar no está diseñado para trabajar con estados de objetos. Por ejemplo: creo una estructura especial, enumero los parámetros del objeto, copio una parte de ella (parámetros seleccionados), nombro esta parte como estado y escribo los valores que corresponden a algún estado del objeto. Luego lo conecto a la estructura principal del objeto.

(2) No existe ningún instrumento de"evento". Es decir, un Evento "flota" en el concepto estándar, pero no puede ser descrito como una enumeración, clase o función. Una simple descripción de un evento en la programación sería muy útil. Por ejemplo: describirlo como una estructura, pero en ella apuntar a los estados "de fondo" del entorno y de los objetos, y apuntar a un cambio clave, que es el desencadenante para iniciar una cadena de otros cambios. De nuevo - la OOP no está afinada para la descripción concisa de eventos y ofrece describirlos en un montón de condiciones, que no tienen nombre y se encuentran "en cualquier lugar".

(3) Además, un parámetro no es un objeto independiente. De hecho - es el objeto más importante, que puede ser modelado y cualquier sistema puede ser ensamblado a partir de sus copias y modificaciones. No lo hace...

Podría seguir y seguir, pero mi mensaje es claro: construye tu OOP y tal vez inventes algo mucho más genial, porque nadie intentó hacerlo seriamente antes que tú. Y el concepto estándar es una visión subjetiva, no física o matemática y puede ser modificado)).

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

hay un patrón de diseño llamado estado

hay un patrón de observadores

El patrón de la bicicleta es el favorito de Peter.
Dmitry Fedoseev  

Реter Konow:

...pero ¿dónde está el concepto filosófico "oficialmente registrado" del Objeto? Desgraciadamente, a día de hoy no existe, ni puede existir. ...

Porque no se basa en absoluto en la filosofía. El Objeto en la programación no es algo sublime, místico o lo que sea que hayas imaginado. Es simplemente una amalgama de funciones y variables.

Vladimir  
Реter Konow:

Este tema será de interés para quienes se preocupan por las cuestiones de programación global.

Me pregunto: "¿por qué el modelo de objetos comúnmente conocido en el concepto estándar de POO es un canon?".

Porque las dos primeras grandes O son lo primero. Como el concepto está orientado a objetos, son la esencia del concepto. De la misma manera que en el concepto de programación procedimental los procedimientos son el punto principal, en SQL las consultas son el punto principal, ignorando cómo se ejecutan, y así sucesivamente. La esencia, no el canon. La canonización de la POO con su oposición a otros enfoques está activamente comprometida en este foro, por eso hay tal impresión.

Koldun Zloy  
Реter Konow:

Este tema será de interés para quienes se preocupan por las cuestiones de programación global.

Bla, bla, bla.

Todo esto no tiene nada que ver con la POO o la programación.

Mejor llamarlo "¿Cuántos objetos caben en la punta de una aguja?".

Реter Konow  
Vladimir:

Porque hay dos O mayúsculas en primer lugar. Como el concepto está orientado a objetos, son la esencia principal del concepto. Así como en el concepto de programación procedimental el punto principal son los procedimientos, en SQL el punto principal son las consultas, ignorando la forma en que se ejecutan, etc. etc. La esencia, no el canon. La canonización de la POO con su oposición a otros enfoques está activamente comprometida en este foro, por eso hay tal impresión.

Hice una pregunta: "¿por qué sólo hay una norma para describir y construir objetos?
Usted ha decidido que mi pregunta es "¿por qué la OOP es canónica?
La orientación a los objetos en la programación estructura, escala e implementa las tareas. No hay duda de ello. Pero, ¿por qué el formato es el mismo?
Реter Konow  
Dmitry Fedoseev:

Porque no se basa en la filosofía en absoluto. El objeto de la programación no es algo elevado o místico o cualquier otra cosa que se pueda pensar. Es simplemente una amalgama de funciones y variables.

Aquí es donde no se puede prescindir de un concepto filosófico. ¿Simplemente fusionar funciones y variables sin seguir un esquema bien pensado del objeto? Se nos dan ciertas herramientas: clases, estructuras, modificadores de acceso... pero podría haber otras herramientas... por ejemplo, el estado, el muestreo, la cartografía... ¿Por qué no? Lo que quiero decir es que el formato OOP y el conjunto de herramientas pueden tener versiones...
Y en ciertos casos, una versión diferente del formato de descripción del objeto puede ser más eficaz.
Razón de la queja: