Uma pergunta para os especialistas do OOP. - página 52

Novo comentário
 

Olhei através do meu novo prisma, um híbrido de OOP e Kernel, para os sistemas de objetos descritos nos programas, e quase explodi meu cérebro. Antes de mais nada, dei uma nova olhada em meus sistemas de GUI. Através de todos esses objetos - parâmetros, objetos-estados, objetos-eventos e manipuladores. Como a GUI e sua tecnologia me é familiar, tudo parecia bastante claro, mas, o sistema é muito complexo. Uma massa de parâmetros, mapeamentos e manipuladores. Cheguei à conclusão de que tais sistemas não podem surgir por si mesmos. E a seleção natural não tem poder aqui.

Eis o porquê:

Cada parâmetro pode ter n número de parâmetros derivados. Digamos: uma mudança de X pode gerar infinitamente muitos parâmetros derivados dos valores desse X em um determinado momento.

Cada parâmetro derivado deve ter um manipulador e um link para outros parâmetros. Nenhum parâmetro existe por si só. O link é obrigatório.

O acoplamento pode ser diferente, e conseqüentemente uma variedade de manipuladores-filtros, corretores, transdutores-canais podem aparecer.

Os eventos que podem ser considerados significativos para os sistemas são indefinidamente muitos. Cada um tem suas próprias propriedades, links e manipuladores. As variações são inumeráveis.

Assim, sem um conceito, nenhum sistema pode surgir. (Muito provavelmente).

Só não está claro como se originou a vida na Terra.

 

Aqui está outro exemplo:

Considere um sistema para mover uma janela com controles em um gráfico.

  • Pegamos dois parâmetros - x e y - do objeto "cursor". A partir deles, criar dois objetos de parâmetro derivados que irão armazenar a diferença entre os valores atuais e passados de x e y. (Os objetos de parâmetro não são apenas variáveis, eles são objetos com suas próprias propriedades).
  • Criar um objeto manipulador para objetos de parâmetros que (1)manipulará os valores x e y, recuperando sua diferença entre os valores atuais e passados no evento do manipulador da janela, que é escrito nas propriedades do manipulador, (2)escrever a diferença para os parâmetros derivados no mesmo evento.
  • Criar um Objeto de Ligação entre os objetos de parâmetro derivados e os objetos de parâmetro x,y de cada objeto de janela, que serão usados para passar valores para eles.
  • Após o Objeto-agravador, criamos mais um objeto Handler, que deve pegar o valor dos parâmetros de objeto x e y de cada objeto de janela e adicionar a ele um valor que vai para o aglutinante.

Assim, com este sistema, podemos mudar as coordenadas de uma janela e seus objetos no caso de seu cabo ser agarrado pelo cursor. Para mover tudo isso, precisamos associar tudo com as funções do ObjectSetInteger handler que mudam a posição do objeto MT no gráfico.

Esta é uma implementação de apenas uma função GUI, ligando blocos especiais do sistema - Object Parameters, Object Handlers, etc...

Construir tal sistema no Kernel, não é um pouco mais fácil (ou talvez até mais difícil) do que escrever código normal sem transformar tudo em um Objeto. Mas, vou continuar cavando...


ZS. Esqueci de acrescentar que, para mover a janela, também precisamos "criar" um Objeto de Evento, que trava o manípulo da janela e o movimento do cursor. E este objeto de evento, conecte-o ao manipulador de objetos dos valores x,y do cursor (que escreve a diferença nos parâmetros derivados), e ele funcionaria apenas no sinal deste evento.

E para cada objeto de evento, você precisa criar um manipulador de objetos e prendê-lo a ele.

Cada manipulador de objetos tem suas próprias propriedades, e os valores que utiliza ao trabalhar com parâmetros ou eventos. Portanto, deve haver um modelo, ou você ficará atolado ao criar tudo isso).

 
Реter Konow:

Aqui está outro exemplo:

Considere um sistema para mover uma janela com controles em um gráfico.

  • Pegamos dois parâmetros - x e y - do objeto "cursor". A partir deles, criar dois objetos de parâmetro derivados que irão armazenar a diferença entre os valores atuais e passados de x e y. (Os objetos de parâmetro não são apenas variáveis, eles são objetos com suas próprias propriedades).
  • Criamos um Objeto Handler para Objetos de Parâmetro que irá (1)lidar com os valores x e y, recuperando sua diferença entre valores atuais e passados no evento Handler da janela, que é escrito nas propriedades Handler, (2)escrever a diferença para os parâmetros derivados no mesmo evento.
  • Criar um Objeto de Ligação entre os objetos de parâmetro derivados e os objetos de parâmetro x,y de cada objeto de janela, que serão usados para passar valores para eles.
  • Após o Objeto-agravador, criamos mais um objeto Handler, que deve pegar o valor dos parâmetros de objeto x e y de cada objeto de janela e adicionar a ele um valor que vai para o aglutinante.

Assim, com este sistema, podemos mudar as coordenadas de uma janela e seus objetos no caso de seu cabo ser agarrado pelo cursor. Para mover tudo isso, precisamos associar tudo com as funções do ObjectSetInteger handler que mudam a posição do objeto MT no gráfico.

Esta é uma implementação de apenas uma função GUI, ligando blocos especiais do sistema - Object Parameters, Object Handlers, etc...

Construir tal sistema no Kernel, não é um pouco mais fácil (ou talvez até mais difícil) do que escrever código normal sem transformar tudo em um Objeto. Mas, vou continuar cavando...


ZS. Esqueci de acrescentar que para mover a janela, também precisamos "criar" um Objeto de Evento, que trava o manípulo da janela e o movimento do cursor. E este objeto de evento, conecte-o ao manipulador de objetos dos valores x,y do cursor (que escreve a diferença nos parâmetros derivados), e ele funcionaria apenas no sinal deste evento.

E para cada objeto de evento, você precisa criar um manipulador de objetos e ligá-lo a ele.

Cada manipulador de objetos tem suas próprias propriedades, e seus valores são utilizados por ele quando trabalha com parâmetros ou eventos. Portanto, deve haver um modelo, ou você ficará atolado ao criar tudo isso).

Difícil. Injustificadamente difícil.
O objeto principal de uma forma, dentro do qual se encontram outros objetos desta forma, é o único que recebe coordenadas. A mudança de qualquer coordenada altera a posição do objeto principal do formulário. Os outros objetos nessa forma são simplesmente passados por coordenadas relativas que determinam sua localização dentro da forma. Todos os objetos têm sua própria ordem na forma, e são rearranjados nessa ordem. Cada objeto tem uma lista do que ele contém dentro dele. A referência à lista de conteúdos permite que cada conteúdo receba um comando de compensação. Assim, ao dar um comando ao objeto da forma para mudar, a cadeia é automaticamente passada para mudar todo o conteúdo da forma. Ou seja, apenas o formulário é compensado, e tudo o mais é automaticamente compensado. Não temos que dar a cada objeto de formulário um comando de compensação por si só.
Fazemos isso por apenas um objeto. Todos os outros irão repeti-lo. Não importa quão complexo seja um objeto de forma, um único comando de compensação será passado para todo o conteúdo dessa forma em uma avalanche.
Tudo é feito apenas uma vez. E então tudo será feito em uma cadeia.
 
Artyom Trishkin:
Complicado. Incomplicado de forma injustificável.
O objeto principal de uma forma, dentro do qual se encontram os outros objetos dessa forma, é o único que recebe coordenadas. A mudança de qualquer coordenada altera a posição do objeto principal do formulário. Os outros objetos no formulário são simplesmente passados por coordenadas relativas que determinam sua posição dentro do formulário. Todos os objetos têm sua própria ordem na forma, e são rearranjados nessa ordem. Cada objeto tem uma lista do que ele contém dentro dele. A referência à lista de conteúdos permite que cada conteúdo receba um comando de compensação. Assim, ao dar um comando ao objeto da forma para mudar, a cadeia é automaticamente passada para mudar todo o conteúdo da forma. Ou seja, apenas o formulário é compensado, e tudo o mais é automaticamente compensado. Não temos que dar a cada objeto de formulário um comando de compensação por si só.
Fazemos isso por apenas um objeto. Todos os outros irão repeti-lo. Não importa quão complexo seja um objeto de forma, um único comando de compensação será passado para todo o conteúdo dessa forma em uma avalanche.
Tudo é feito apenas uma vez. E então tudo será feito em uma cadeia.

É isso mesmo.

A ligação entre parâmetros derivados contendo a diferença x,y do cursor e objetos de forma (que estão na cadeia) tem um manipulador no centro que pode realizar uma conexão serial com os parâmetros x,y de cada objeto de forma. Ou seja, os parâmetros de ligação através do manipulador de conexão serial permitem substituir a ligação de cada objeto de formulário por parâmetros derivados que passam valores de diferença x,y. Eu também estava pensando sobre isso.

Em minha GUI, a movimentação de janelas é implementada dentro da função de fazer o seguinte:

(1) Verificador de eventos para a maçaneta da janela clique evento

(2) Mover evento do cursor

(3) Cálculo da diferença entre as coordenadas do cursor atual e as coordenadas do cursor anterior

(4) Ciclar através dos objetos da janela e mudar suas coordenadas, ajustando a diferença na posição do cursor.

(5) Chamando o ObjectSetInteger para mover o МТ-objeto do formulário da janela (lona) ao longo do gráfico pela distância dada.


Portanto, a implementação dentro da função é correta. A implementação através de Object Handlers, Object Parameters e Object Bindings parece estranha contra este pano de fundo. Mas, vamos cavar...

 
Реter Konow:

Isto é correto.

O mapeamento entre os parâmetros derivados contendo a diferença x,y do cursor e os objetos de formulário (que estão na cadeia) tem um manipulador no meio que pode realizar uma conexão serial com os parâmetros x,y de cada objeto de formulário. Ou seja, os parâmetros de ligação através do manipulador de conexão serial permitem substituir a ligação de cada objeto de formulário por parâmetros derivados que passam valores de diferença x,y. Eu também estava pensando sobre isso.

Em minha GUI, a movimentação de janelas é implementada dentro da função de fazer o seguinte:

(1) Verificador de eventos para a maçaneta da janela clique evento

(2) Mover evento do cursor

(3) Cálculo da diferença entre as coordenadas do cursor atual e as coordenadas do cursor anterior

(4) Ciclar através dos objetos da janela e mudar suas coordenadas, ajustando a diferença na posição do cursor.

(5) Chamando o ObjectSetInteger para mover o МТ-objeto do formulário da janela (lona) ao longo do gráfico pela distância dada.


Portanto, a implementação dentro da função é correta. A implementação através de Object Handlers, Object Parameters e Object Bindings parece estranha contra este pano de fundo. Mas, vamos cavar...

Sim, porque você não precisa separar estes manipuladores do objeto. A classe que retorna as coordenadas do cursor pode ser tornada estática - ela estará disponível para qualquer classe do programa, e a obtenção das coordenadas e a resposta a elas deve ser implementada em cada objeto. Mas somente o objeto principal do formulário deve chamar esses manipuladores. Então, para todos os outros objetos de formulário, é suficiente especificar novas coordenadas e redesenhar. Dentro do objeto forma, há uma lista de todos os seus objetos. O objeto forma definiu mudança de suas coordenadas - define novos valores para suas coordenadas, passa por sua lista de objetos e métodos de chamadas para definir coordenadas de cada objeto em sua lista. Ao mesmo tempo, cada objeto subseqüente faz a mesma coisa quando suas coordenadas mudam - ele olha através de sua lista de objetos e ordena que eles mudem suas coordenadas. Os objetos das listas estão dispostos na ordem em que são desenhados (seqüência Z). Em outras palavras, cada objeto tem seu próprio método de mudança de coordenadas, mas é implementado da mesma maneira - ele olha através da lista de todos os objetos "amigáveis" e chama o mesmo método para cada um deles. Assim, ao chamar este método uma vez para o objeto principal do formulário, iniciamos automaticamente uma mudança de coordenadas para todos os objetos do formulário. Quando a lista de objetos "amigáveis" do formulário foi processada, ele chama seu método de redesenho do gráfico, que é o mesmo para todos os objetos modificados.

 
Artyom Trishkin:

...

Esta é a visão padrão OOP do mecanismo de movimentação de janelas. Vou lhe mostrar um diferente. Para fazer isso, limpe sua mente por um segundo e apenas siga meu pensamento.

  1. Imagine uma matriz de matriz. As dimensões são indefinidas. Talvez seja infinito, talvez não. Isso não importa.
  2. A matriz é inicializada com zeros. Os zeros representam o vazio. Ou seja, a matriz está vazia.
  3. Na vacuidade da matriz, algo além do vazio apareceu. É um zero substituído por um valor. Não importa o que seja.
  4. Vemos este valor na matriz vazia e dizemos "este é um parâmetro". Isto é, não o valor em si - mas a célula em que ele apareceu. A célula é honrada com o título e chamada de parâmetro - ou seja, a "capacidade" que contém o valor.
  5. O parâmetro exige de nós imediatamente sua definição. É como se estivesse dizendo "Eu sou um parâmetro, e tenho uma personalidade! Onde estão minhas propriedades?!". E não temos outra escolha senão acrescentar ao parâmetro suas propriedades, que também são parâmetros com seus próprios valores. Colocamo-los junto a ela e temos uma cadeia - um parâmetro e suas propriedades. Nós dizemos "criamos um Parâmetro Objeto".
  6. A seguir, o parâmetro "diz": "Onde estão os outros parâmetros?! Por que eu sou o único"? E então criamos mais alguns parâmetros no vazio da matriz, para que o "primogênito" não fique entediado. Naturalmente, cada um dos novos parâmetros declara sua individualidade e exige propriedades como seus portadores. Assim, crescem cadeias de parâmetros, entre os quais se encontram os "primogênitos" e suas propriedades. Nós dizemos "Criamos Objetos Parâmetros".
  7. Agora, no vazio da matriz, temos vários parâmetros com cadeias de suas propriedades. Mas cada um deles "grita" sobre a falta de significado de sua existência. Cada um deles está sozinho. Então, decidimos ligar os parâmetros para que eles não fiquem "entediados". Para fazer isso, criamos parâmetros especiais que servem de ligação entre outros parâmetros. Eles também consistem em cadeias de propriedades. Agora, os parâmetros primogênitos estão ligados entre si por um encadeamento de parâmetros. Todos estão felizes! Dizemos: "Criamos Objetos de Ligação de Parâmetros".
  8. Mas, então, acontece que os parâmetros-primeiro querem se comunicar e transferir valores uns para os outros por meio de encadernações, mas as encadernações prevêem a transferência de valores (linguagem dos parâmetros), mas não prevêem a tradução. E estando sozinhos, os parâmetros entendem apenas sua linguagem, o que significa que existe uma "barreira lingüística" entre os parâmetros e eles exigem que nós a resolvamos.
  9. A fim de resolver o problema da "comunicação de parâmetros" não tínhamos mapeamentos suficientes, precisávamos de uma tradução. Isto significa que os valores passados entre os parâmetros precisam ser convertidos, levando em conta as propriedades de cada parâmetro. Alguns deles entendem valores na faixa 1-10, e outros entendem (-5) - (-105). Alguns operam com números fracionários, outros com potências. Portanto, concluímos que precisamos de "tradutores", ou seja, manipuladores de valores que levem em conta as propriedades dos parâmetros. Criamos Objetos Handler especiais e os inserimos em mapeamentos de parâmetros. Objetos de Valor Handler "traduzem" os valores passados entre parâmetros usando as propriedades dos parâmetros que passam e recebem, e suas próprias propriedades. Nós dizemos - "Nós criamos Handler Objects! Agora os parâmetros podem se comunicar livremente".
  10. Os parâmetros primogênitos estavam se comunicando e se cansando disso. Cansado disso. Então eles decidiram que se comunicariam apenas em ocasiões especiais - bem, quando um deles recebe um valor incrível. Mas, no final das contas, precisávamos estar de olho no valor, como uma criança, implacavelmente. Os parâmetros primogênitos nos pediram para pensarmos em um "sistema de monitoramento" que sinalizasse variações incomuns para que eles não se preocupassem com isso. Assim, fizemos um molde dos valores aos quais deveríamos reagir e acrescentamos um manipulador especial a ele, o que resultou em um "objeto de evento". Nós o conectamos a cada parâmetro e eles começam a se comunicar uns com os outros usando sinais de Objetos de eventos. Assim, criamos os "Eventos-objetos".

Esse é o fim da história...

Olhamos para a matriz por fora e gaseamos! "Criamos um Sistema de Objetos!")

ZS. Note que tudo pode ser criado em uma matriz de matriz. E a matriz-matriz é o núcleo. E as entidades nela contidas - os verdadeiros objetos. E parâmetros, e eventos, e encadernações, e propriedades, e manipuladores. Há inúmeros sistemas que podem ser construídos no Kernel a partir dessas coisas básicas.

 

Uma continuação falsa...

11. De alguma forma, os parâmetros dos primogênitos decidiram seguir uma moda. Eles descobriram que existe uma feira de imóveis em algum lugar da matriz, e um certo espaço na novidade. Dizem que tem três propriedades. As "dimensões" são chamadas de "dimensões". Estas propriedades têm uma faixa supostamente infinita de valores, e como um bônus elas dão outro "tempo parâmetro". Os parâmetros chegaram à feira e tomaram as propriedades x,y,x_tamanho,y_tamanho. Eles dizem que querem fazer uma concha no espaço. E eles também ganharam cor. Eles voltaram e começaram a vestir as novas propriedades. Eles modelaram e modelaram alguns envelopes espaciais até se cansarem disso. Cresceram imensamente, depois desabaram... Depois puseram cores em si mesmos e relaxaram. Eles começaram a pensar no que fazer a seguir. E então eles olharam para a caixa de propriedade de tempo. Vamos ver o que é... Eles o abriram, prenderam-no a si mesmos, mas não calcularam os valores e em um momento ele se evaporou no vazio. Afinal, o tempo é um parâmetro com o qual se deve ter muito cuidado...

 
Реter Konow:

Uma continuação falsa...

11. De alguma forma, os parâmetros dos primogênitos decidiram seguir uma moda. Eles descobriram que existe uma feira de imóveis em algum lugar da matriz, e um certo espaço na novidade. Dizem que tem três propriedades. As "dimensões" são chamadas de "dimensões". Estas propriedades têm uma gama supostamente infinita de valores, e como um bônus elas dão outro "tempo parâmetro". Os parâmetros chegaram à feira e tomaram as propriedades x,y,x_tamanho,y_tamanho. Eles dizem que querem fazer uma concha no espaço. E eles ganharam cor. Eles voltaram e começaram a vestir as novas propriedades. Eles modelaram e modelaram alguns envelopes espaciais até se cansarem disso. Cresceram imensamente, depois desabaram... Depois puseram cores em si mesmos e relaxaram. Eles começaram a pensar no que fazer a seguir. E então eles olharam para a caixa de propriedade de tempo. Vamos ver o que é... Eles o abriram, prenderam-no a si mesmos, mas não calcularam os valores e em um momento ele se evaporou no vazio. Afinal de contas, o tempo é um parâmetro com o qual você tem que ter muito cuidado...

E os dez primeiros não foram sérios?

Eu, por exemplo, não consigo ler sem rir.

 
Artyom Trishkin:

...

Toda essa "objetividade" é muito confusa, você não concorda? Você tem que ter cuidado com isso. Nikolai Semko estava certo sobre a proximidade de genialidade e esquizofrenia. É possível "ficar louco". Há algumas coisas que é melhor não entender. Algumas portas, devem estar sempre fechadas para nossa Consciência. Como disse um filme, - "o parasita mais perigoso é uma idéia". Uma vez no cérebro, é impossível tirá-lo de lá". A matriz de que eu estava falando é perigosa para a Mente. É fácil se perder nele e ficar perdido para sempre. Vamos ter cuidado))))

 
A representação de sistemas na Matrix dá uma nova perspectiva sobre suas estruturas, mas não vi nenhuma pista de facilitar a criação de sistemas. Para não mencionar qualquer "autodesenvolvimento". É muito interessante ver os sistemas dessa maneira, mas não mais do que isso. Não vejo nenhum autodesenvolvimento ou mesmo uma pitada dele. Portanto, vamos deixar o divino para Deus. Nenhum autodesenvolvimento de sistemas pode ser alcançado nem pela abordagem padrão do OOP, nem pela minha.
1...4546474849505152535455
Novo comentário
Razão: