Minha abordagem. O núcleo é o motor. - página 4

 
O OOP não interfere na implementação do kernel, pelo contrário.
Normalmente há código e dados. O núcleo, em nosso caso, é o código, fortemente separado dos dados. Os dados também podem ser o próprio código. O núcleo geralmente tem uma funcionalidade mais completa para lidar com dados específicos, ou pelo menos algum mínimo auto-suficiente.
Esta abordagem permite que você utilize o formato de dados mais conveniente, presume-se que haverá muitos dados.
Aqui está outro exemplo onde essa abordagem pode ser aplicada: há muitas estratégias no Expert Advisor, os dados representam apenas a lógica das estratégias, o núcleo é a funcionalidade para gerenciá-las, ou seja, gerenciamento de ordens, gerenciamento de risco, trabalho com o ambiente de negociação, indicadores, tratamento de erros, exibição de algumas ou todas as estatísticas, funções trailing/grid/.....
 

Реter Konow:

Você cria um array e escreve os valores das propriedades do botão que você deseja criar nele.

Um botão consiste em três objetos: Base, Texto, Imagem.

Cada objeto existe dentro de um Elemento de Botão, portanto, a matriz deve ser bidimensional.

Então, por que se preocupar com todas essas matrizes quando você pode (e deve) usar uma estrutura para isso. E podemos abordar estes valores humanamente - por nome de campo, não por índice (o que pode causar muitos erros bobos).

Como resultado, em vez de uma matriz bidimensional, haverá uma série de estruturas. A declaração é a mesma concisa, mas a simplicidade e confiabilidade é muito maior, além do uso racional da memória, pois cada campo tem seu próprio tipo. E o OOP não tem nada a ver com isso.

Aqui está um exemplo:

struct TObject { char type;  string name;  int x;  int y;  int width;  int height;  color clr; };

TObject Objects[]= { { OBJ_BITMAP, "Bitmap", 100, 100, 200, 200, clrRed },
                     { OBJ_BUTTON, "Button", 150, 150, 50, 10, clrWhite },
                   };
 
Alexey Navoykov:


O resultado é um conjunto de estruturas em vez de um conjunto bidimensional. A declaração é a mesma, mas a conveniência e a confiabilidade são muito maiores, além do uso racional da memória, pois cada campo tem seu próprio tipo. E o OOP não tem nada a ver com isso.


É meio ambíguo... o que é melhor - um conjunto de estruturas ou uma estrutura de matrizes?

mas a MQL foi projetada para trabalhar com matrizes Forthran, isso é um fato...

 
Maxim Kuznetsov:

Há um pouco de dilema aqui... o que é melhor - um conjunto de estruturas ou uma estrutura de matriz?

De que tipo de estrutura de matriz estamos falando? O autor tem apenas matrizes

 

Acho que Peter nunca viu como criar um modelo DialogBox em Visual C++, arrastar e soltar quaisquer Controles nele, tais como Botão, CheckBox, EditBox, ComboBox, etc.

Em outras palavras, os elementos que você pode ver no Windows, incluindo diferentes opções de exibição de strings DB com ajustes de campo e string.

E com o uso do MFC você pode fazer caixas de diálogo bastante complexas em poucos minutos e muito rapidamente.

 
Alexey Navoykov:

E por que todas estas perversões com uma matriz, quando você pode (e deve) usar uma estrutura para este fim. É inicializada exatamente da mesma forma - com valores, separados por vírgulas. E estes valores podem ser acessados humanamente - por nome de campo, não por índice (o que pode levar a muitos erros bobos).

Como resultado, em vez de uma matriz bidimensional, haverá uma série de estruturas. A declaração é a mesma concisa, mas a simplicidade e confiabilidade é muito maior, além do uso racional da memória, pois cada campo tem seu próprio tipo. E o OOP não tem nada a ver com isso.

Aqui está um exemplo:

É uma boa solução. Mas esta estrutura não pode ser integrada no núcleo. Se ao construir um núcleo de acordo com minha tecnologia, você só precisa fazer um loop na matriz com os elementos do protótipo e reescrevê-los no núcleo, no caso de sua solução, o loop é impossível.

Embora isso pudesse ser possível, mas cada elemento deve ser envolto em uma estrutura separada. E como exibi-la no âmbito global? Onde declarar tudo isso... Não está claro.

O meu é simples. Um conjunto de protótipos de elementos. Todas as propriedades dos objetos estão dentro dele. A matriz em si é global. O acesso é o mais simples e de qualquer lugar do programa.

 
Seu instinto não resiste ao uso de duplas? Afinal de contas, é também um objeto composto com seus próprios métodos. Não há lugar para eles em matrizes ortodoxas de miolo! Veja, porque é impressionante (mantissa, expoente, sinal):
_NEW_OBJECT, тра-та-та-та-та-та, 3, 10, 1, тра-та-та-та-та-та
 
pavlick_:
Seu instinto não resiste ao uso de duplas? Afinal de contas, é também um objeto composto com seus próprios métodos. Não há lugar para eles nas matrizes ortodoxas do núcleo! Veja, é impressionante (mantissa, expoente, sinal):

Eu não entendo.

 

Eu me livro de sintaxe e pandeiro desnecessários, eu simplesmente inicializo as propriedades dos elementos em uma matriz de protótipos globais.

É usado apenas uma vez - quando os protótipos de elementos são reescritos no Kernel.

A reescrita é feita em um loop simples.

Como resultado, na fase de construção, o Kernel começa a conter protótipos de elementos selecionados pelo usuário.

Em seguida, começam novos ciclos sobre o Kernel. Neles, escrevo os valores definidos pelo usuário das propriedades dos elementos.

No final, você recebe um Kernel acabado, que contém as janelas do usuário acabado com todos os elementos.

 

O processo descrito acima, eu chamo o "processo de construção do núcleo".

Depois que o núcleo é construído, o "motor" começa a funcionar.

O motor é o código que controla a mecânica dos elementos.

O motor só é treinado para trabalhar com o Kernel. Seu motor são vários eventos (a maioria proveniente da OnChartEvent()).