Representação de um objeto na programação. - página 9

Novo comentário
 
JRandomTrader #:

Em que estão escritos os "apêndices"?

Em idiomas de aplicação.

 

Parte 2.

Na primeira parte, falamos sobre os constituintes do Objeto, mas nesta parte vamos analisar suas relações uns com os outros. Os próprios componentes serão convencionalmente chamados"Proto-blocos", porque não são objetos de pleno direito, mas representam algumas entidades "construtivas" que fazem parte de todos os objetos e sistemas. Deixe-me lembrá-lo de sua lista inicial:

  • Parâmetro - uma representação nomeada e numericamente comprimida de um determinado conjunto estrutural ou valor.
  • Um conjunto de propriedades - a lista de parâmetros incluídos no Objeto.
  • Função Construtora- Um algoritmo que reproduz um objeto com base em uma lista de seus parâmetros.
  • Forma- Combina um tipo de conjunto pertencente a um Objeto, que existe em duas ou três dimensões.
  • Estados-"breakpoints"significativos na existência do Objeto, valores de parâmetros para os quais o Objeto passa na mudança das condições ambientais ou no processo de execução independente de um programa .
  • Eventos - mudanças significativas no próprio Objeto ou em seu entorno.
  • Processos - várias seqüências de mudança de estados do(s) Objeto(s), resultantes damudança das condições do ambiente externo ou da execução independente de um programa.

Além do "corpo" paramétrico de Forma, Estado, Evento e Processo, adicionaremos uma função de manipulador (vamos chamá-lo simplesmente "manipulador") cuja tarefa é "transferir" valores de seu proto-bloqueio para o conjunto paramétrico do Objeto. Por exemplo: uma Etiqueta tem 5 parâmetros em uma função construtora e este conjunto é seu "corpo" paramétrico. Suponha que inventamos um novo estado e o escrevemos como valores diferentes dos parâmetros iniciais, e no momento em que precisamos mover o Rótulo para um novo estado, precisamos chamar uma função que os transfira da estrutura paramétrica do Estado para o "corpo" paramétrico do Rótulo. Simplificando, este manipulador inicializa os parâmetros do objeto com os valores de seu proto-bloqueio. Para Processo e Forma, princípio semelhante funciona com transferência de valor para o corpo do Objeto, mas a implementação é diferente. Mas para processarum Evento não precisamos transferir os valores - precisamos verificá-los, então uma declaração de condição fará como um manipulador.

Há muitos manipuladores em meu conceito e eles merecem uma classificação separada, mas isso complicaria demais a apresentação e, portanto, vou tocá-los superficialmente, dividindo-os aproximadamente em vários grupos:

  • "Transportadores" - Manipuladores que transferem valores de um proto-bloqueio para um Objeto (por exemplo, de um Estado, Formulário, Processo para os parâmetros de destino de um Objeto).
  • "Bound" - Manipuladores que mudam os valores dos parâmetros vinculados (dependentes) no sistema (por exemplo - uma trajetória parabólica de movimento implica uma mudança síncrona dos valores das coordenadas e isto é implementado por um manipulador vinculado x,y). As dependências nas relações de parâmetros podem ser expressas por fórmulas, ou definidas por condições incluídas no corpo do manipulador.
  • "Montadores" - Manipuladores que "constroem" novos proto-blocos, "desempacotando-os" do corpo paramétrico do objeto e salvando-os com os importantes valores atuais, ou "clonando" outros proto-blocos, parcial ou completamente, e fazendo as alterações necessárias nas cópias. Neste processo, as estruturas tabulares ou hierárquicas são formadas a partir dos proto-blocos, que são dispostos dentro de "módulos" especiais nos quais eles são armazenados.
  • "Modular" - Manipuladores de diferentes tipos de módulos nos quais os proto-blocos são armazenados. *(Sobre os "módulos" dos proto-blocos serão descritos mais adiante).

Esta não é de forma alguma uma lista completa e os nomes dos manipuladores são arbitrários, mas a divisão de sua especialização, em geral, se parece com isto.


A próxima adição ao conceito após as funções de manipulador seria"Módulos". É lógico assumir que os proto-blocos criados devem ser armazenados e organizados em algum lugar, e também é fácil de adivinhar, que seria ideal separar o armazenamento de proto-blocos de diferentes tipos para evitar confusão e permitir que os manipuladores "naveguem" facilmente através do conteúdo crescente do Objeto. Assim, criamos "armazéns" ou, como é ainda mais bonito,"Módulos" de proto-blocos. Para os Estados, Processos, Eventos e Formas do objeto serão criados seus próprios módulos nos quais serão criados os proto-blocos:

  1. Armazenado de forma ordenada.
  2. Multiplicar.
  3. Recuperar por manipuladores, conforme necessário.
  4. Link para proto-blocos em outros Módulos.

O quarto ponto - de "ligar" proto-blocos de diferentes tipos é precisamente baseado em sua "inclusão estrutural" uns nos outros, do qual falei na primeira parte - Processo inclui Estados,... Evento inclui Estado,... Um processo inclui Eventos,... Um Estado pode incluir um Formulário e assim por diante... Por exemplo, se construirmos um modelo de evento em um módulo separado, então sua hierarquia de condições conterá Eventos que são armazenados no módulo 'Evento', e estes Eventos, por sua vez, contêm Estados que são armazenados no módulo Estados. Desta forma, não apenas criamos uma ordem eficiente de armazenamento e uso de proto-blocos, mas também implementamos sua "inclusão estrutural" simplesmente conectando-os uns aos outros por meio de ligações entre os módulos. Mudando arbitrariamente ou pensativamente os elos, podemos criar novos proto-blocos a partir dos existentes, bem como mudar o evento ou modelo lógico no "comportamento" do Objeto. Mudar as relações no nível do modelo lógico (que por sua vez será armazenado em seu módulo) pode mudar completamente o programa e, ao fazê-lo, não temos que reescrever nada no código. É aqui que eu vejo os benefícios da partição modular proto-bloqueio.

Isso é tudo por enquanto. Em seguida, passarei aos modelos de eventos e lógica e considerarei como eles são construídos.

Faça perguntas se alguma coisa não estiver clara ou interessante.


 
Para que serve o conceito?
 
Aliaksandr Hryshyn #:
Para que serve o conceito?

Este conceito é uma tentativa de passar para o próximo nível de programação, que em minha opinião será "construir" (em vez de escrever) sistemas funcionais pelo próprio computador, em vez de pelo ser humano. O software será capaz de criar programas.

Existe agora uma rede neural treinada em código githab, mas não é nada disso que quero dizer.

 
Há uma coisa que não consigo entender, eu estabeleço valores para a linha de tendência ObjectCreate(...), a linha não aparece na tela. Por favor, ajude-me, como exibir um objeto?
 
Реter Konow #:

Este conceito é uma tentativa de passar para o próximo nível de programação, que em minha opinião será "construir" (em vez de escrever) sistemas funcionais pelo próprio computador, em vez de pelo ser humano. O software será capaz de criar programas.

Existe agora uma rede neural treinada em código githab, mas não é nada disso que quero dizer.

Olá Peter.
Além do OOP existe também o DDD(Domain-driven design)
apenas para mantê-lo informado.

 
Nikolai Semko #:

Olá Peter.
Além do OOP, há o DDD(Domain-driven design)
Só para que você saiba.

Você está confundindo o quente e o suave.

 
Andrei Trukhanovich #:

Você está confundindo o quente e o suave.

Você também está confundindo quente com frio
 
Vladimir Baskakov #:

Onde está o sinal, mano?

 
Andrei Trukhanovich #:

Onde está o sinal, mano?

Onde está o seu?
1234567891011121314151617
Novo comentário