Representação de um objeto na programação.

 

Este tópico será de interesse para aqueles que estão preocupados com questões de programação global.

A pergunta que me preocupa é "por que o conhecido modelo Object no cânone padrão do conceito OOP?". Quer dizer, um Objeto é uma entidade que as pessoas descrevem em palavras toda vez que dizem a palavra. Com o advento da programação, uma tentativa de descrever o Objeto por código foi logicamente conectada e uma tecnologia especial foi inventada para fazê-lo, mas aqui está a pergunta: por que apenas um? Como se a primeira língua substituísse completamente as outras e não as deixasse evoluir. Isto é impossível nos tempos antigos, mas possível na era do globalismo e da propaganda. E assim aconteceu - uma representação do Objeto conquistou o mundo e bloqueou as direções de outras idéias.

Eu teria aceito a concepção padrão do Objeto há muito tempo, se eu (como filósofo) não tivesse tido algumas reclamações sobre ele.

  1. Antes de mais nada, um prefácio: um passo evolutivo na programação foi dado quando a tese principal foi declarada - a programação toma como base "objetos" e qualquer programa deve logicamente invadi-los. Ou seja, não escrevemos mais algoritmos (seqüências de operações), mas criamos "entidades". Algoritmos, por outro lado, colocamos em sua estrutura para que se tornem parte de um "conjunto" geral de interações. Por quê? - É mais eficiente dessa forma. MAS, eis a questão: onde está o conceito filosófico "oficialmente registrado" do Objeto? Infelizmente, não existe até hoje, nem pode existir.

Isto significa que os autores do conceito OOP agiram arbitrariamente, confiando na "infalibilidade" de suas noções filosóficas.

2. Aqui, estão algumas das minhas reivindicações:

(1) Por que o conceito padrão não tem uma ferramenta". O estado de"? Os objetos não têm estados? Um estado pode ser descrito em uma estrutura, mas isso é inconveniente. O conceito padrão não foi projetado para trabalhar com estados de objeto. Por exemplo: eu crio uma estrutura especial, listo os parâmetros do objeto, copio uma parte dele (parâmetros selecionados), nomeio esta parte como um estado e escrevo valores que correspondem a algum estado do objeto. Em seguida, eu o conecto à estrutura principal do objeto.

(2) Não há nenhum instrumento de"evento". Quero dizer, um Evento "paira" no conceito padrão, mas não pode ser descrito como uma enumeração, classe ou função. Uma simples descrição de um evento na programação seria útil. Por exemplo: descreva-a como uma estrutura, mas nela aponta para estados "de fundo" de ambiente e objetos, e aponta para uma mudança chave, que é o gatilho para iniciar uma cadeia de outras mudanças. Novamente - O OOP não é afiado para descrição concisa de eventos e se oferece para descrevê-los em um monte de condições, que não têm nome e estão localizados "em qualquer lugar".

(3) Além disso, um parâmetro não é um objeto independente. Na verdade - é o objeto mais importante, que pode ser modelado e qualquer sistema pode ser montado a partir de suas cópias e modificações. Não...

Eu poderia continuar e continuar, mas minha mensagem é clara: construa seu OOP e talvez você invente algo muito mais legal, porque ninguém tentou fazer isso seriamente antes de você. E o conceito padrão é uma visão subjetiva, não física ou matemática e pode ser modificado))).

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

há um padrão de design chamado estado

há um padrão de observador

há o padrão da bicicleta. é o padrão preferido de Pedro.
 

ambos C# e Delphi têm propriedadeshttps://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/properties

e as ovelhas não são um truque por muito tempo

mas, em minha opinião, outro tópico sobre a letra de uma canção bastante boa "Fada" - YazheVik .... Você vai e eu sou uma fada! ....

 
De modo geral, ao definir o Objeto, deve-se definir também o Sujeito, caso contrário esta é uma descrição incompleta do mundo, além de que nos conceitos filosóficos mais modernos existe a Trajetória com um status relacional independente como um elo intermediário/ligação entre o Objeto e o Sujeito.
 

Peter, entrando do lado errado novamente. Por que o Estado deve ser uma ferramenta? O Estado foi e é, não foi a lugar algum, é ainda mais primordial do que tudo o mais. E sim - um evento não é um estado, portanto não é descrito, mas registrado.

 

Реter Konow:

...mas onde está o conceito filosófico "oficialmente registrado" do Objeto? Infelizmente, não existe até hoje, nem pode haver ... ...

Porque não se baseia de forma alguma na filosofia. O Objeto na programação não é algo sublime, místico ou qualquer outra coisa que você poderia ter imaginado. É simplesmente uma amálgama de funções e variáveis.

 
Реter Konow:

Este tópico será de interesse para aqueles que estão preocupados com questões de programação global.

Estou me perguntando: "por que o modelo de objeto comumente conhecido no conceito padrão do OOP é um cânone?".

Porque os dois primeiros grandes O's vieram primeiro. Uma vez que o conceito é orientado ao objeto, eles são a essência do conceito. Da mesma forma que na programação processual os procedimentos conceituais são o ponto principal, nas consultas SQL são o ponto principal, ignorando como eles são executados, e assim por diante e assim por diante. A essência, não o cânone. A canonização do OOP com sua oposição a outras abordagens está ativamente engajada neste fórum, e é por isso que existe uma tal impressão.

 

Em vez de reinventar sua própria bicicleta, você deve estudar a teoria do tipo e praticar sua aplicação à programação em linguagens funcionais (por exemplo, Haskel).

Para uma compreensão dos fundamentos filosóficos e lógicos, você pode ler Bertrand Russell.

 
Реter Konow:

Este tópico será de interesse para aqueles que estão preocupados com questões de programação global.

Blá blá blá blá.

Tudo isso não tem nada a ver com OOP ou programação.

Melhor chamá-lo de "Quantos objetos podem caber na ponta de uma agulha".

 
Vladimir:

Porque há dois O's de capital em primeiro lugar. Como o conceito é orientado ao objeto, eles são a essência principal do conceito. Da mesma forma que no conceito de programação procedural o ponto principal são os procedimentos, em SQL o ponto principal são os pedidos ignorando a forma como são executados, etc., etc. A essência, não o cânone. A canonização do OOP com sua oposição a outras abordagens está ativamente engajada neste fórum, e é por isso que existe uma tal impressão.

Eu fiz uma pergunta: "por que existe apenas um padrão para descrever e construir objetos"?
Você decidiu que minha pergunta é "por que o OOP é um cânone?
Orientação a objetos em estruturas de programação, escalas e tarefas de implementação. Não há dúvidas sobre isso. Mas, por que o formato é o mesmo?
 
Dmitry Fedoseev:

Porque não se baseia em filosofia de forma alguma. O objeto na programação não é algo sublime ou místico ou qualquer outra coisa que você possa pensar. É simplesmente uma amálgama de funções e variáveis.

É aqui que não se pode passar sem um conceito filosófico. Simplesmente fundir funções e variáveis sem seguir um plano bem pensado do objeto? Nos são dadas certas ferramentas: classes, estruturas, modificadores de acesso... mas poderia haver outras ferramentas... por exemplo, estado, amostragem, mapeamento... por que não? Meu ponto é que o formato OOP e o kit de ferramentas podem ter versões...
E em certos casos, uma versão diferente do formato de descrição do objeto pode ser mais eficaz.
Razão: