Minha abordagem. O núcleo é o motor. - página 14
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
O formato é simples, mas não é um trabalho em andamento. Quero dizer, quando há muitas propriedades nos objetos.
Aqui está um exemplo de sua abordagem, realmente utilizada, os princípios são os mesmos. Análise léxica do texto, é muito difícil fazer qualquer coisa manualmente. Somente automação. E não diga que é conveniente.
O conjunto de protótipos mostrado é o resultado da inicialização manual das propriedades do objeto com valores padrão. É visto apenas pelo desenvolvedor.
Kernel Principal - é compilado automaticamente a partir de protótipos de elementos. Depois, os protótipos são convertidos em elementos concretos. Também automaticamente.
Quanto a trabalhar com o construtor, há palavras-chave simples e forma conveniente de desenho. Não existem tais tabelas ali.
Aqui está outro exemplo que se encaixa em sua idéia, apenas um monte de elementos dinâmicos. Há estratégias inteiras, três delas no exemplo. Não há muita conveniência aqui. No arquivo anexo.
Ou seja, para manter a dimensionalidade da matriz, alguns de seus objetos têm propriedades falsas. É muito flexível, não se pode dizer nada sobre isso.
Infelizmente, temos que tolerar temporariamente este inconveniente. Por outro lado, um núcleo bidimensional fornece acesso extremamente conveniente e rápido, construindo em laços e muito mais. Se você fizer um kernel unidimensional, não haverá propriedades "falsas". Mas a conveniência se tornará muitas vezes menor. Ou, você poderia simplesmente colocar o texto e as propriedades do ícone em uma série de propriedades do núcleo. E o problema será eliminado. Fá-lo-ei no futuro.
Aqui está outro exemplo que se encaixa em sua idéia, apenas um monte de elementos dinâmicos. Há estratégias inteiras, três delas no exemplo. Não há muita conveniência aqui. No arquivo anexo.
Inicialmente adverti os leitores que minha abordagem não visa a conveniência de um programador. Estou oferecendo a concepção do desenvolvimento mais poderoso e rápido de um programa.
É claro, eles dirão que o desenvolvimento mais rápido de um programa é conectar blocos prontos. Sim, mas a qualidade do programa cai e as despesas gerais crescem. Unir blocos não é a melhor solução em termos de eficiência.
Inicialmente adverti os leitores de que minha abordagem não está focada na programação amigável. Ele oferece o conceito de desenvolvimento mais poderoso e rápido de um programa.
É conveniente quando o programador não modifica/cria diretamente tais dados.
A utilização de códigos que funcionam com tais dados é bastante útil.
Inicialmente adverti os leitores de que minha abordagem não está focada na programação amigável. Ele oferece o conceito do programa mais poderoso e mais rápido de desenvolvimento.
Como estes dois pontos podem coexistir: falta de conveniência para o programador e desenvolvimento rápido do programa? Como você pode desenvolver um programa rapidamente se ele não for conveniente?
Qual é o problema com o controle? Adicionar uma propriedade e aumentar o tamanho das fileiras de Kernel. Isso é tudo.
E o que você fará se for necessário fazer não um botão retangular, mas circular ou triangular?
Se você usar OOP, você criará um botão de classe base Button, que tem um método abstrato Draf e é responsável por desenhar botões. Para um botão redondo, você precisará criar um herdeiro de Button, que será suficiente para anular o método Draf, que implementará o desenho do botão redondo. Para um botão retangular, também será suficiente criar um herdeiro de Botão e anular o método Draf para desenhar um botão retangular.
Como seria tudo isso se você usasse seu método?
Aqui está outro exemplo que se encaixa em sua idéia, apenas um monte de elementos dinâmicos. Há estratégias inteiras, três delas no exemplo. Não há muita conveniência aqui. No arquivo anexo.
De jeito nenhum!
É uma coisa linda... é um autômato empilhável.
com um conhecimento mínimo de assembler e Forth, é uma brisa para ler. Se houvesse comentários, não seria mais complicado do que a MQL.
Isto é útil quando o programador não modifica/cria diretamente tais dados.
A utilização de códigos que funcionam com tais dados é bastante útil.
Você verá, uma vez é criado um conjunto de protótipos. E então, raramente é mudado MUITO. Somente em caso de modificações sérias no programa.
De jeito nenhum!
É uma coisa linda... uma máquina de empilhamento claro.
Se você conhece assembler e Forth o mínimo possível, é fácil escrever, então é uma brisa para ler. Se houvesse comentários, não seria mais complicado do que a MQL.
É uma engenhoca legal). Você concorda, que é mais fácil escrever programas em MQL do que em assembler. Estou falando de usabilidade, eficiência.