Representação de um objeto na programação.
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! ....
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.
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.
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".
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.
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.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
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.
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))).