Minha abordagem. O núcleo é o motor. - página 135
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
Há ali um problema diferente. A limitação dos elementos e parâmetros centrais. Eu sei qual deve ser a solução. Eu simplesmente ainda não tive a oportunidade de fazê-lo.
É por isso que estou perguntando. Se você tem 21 cordas costuradas na amêndoa, não é muito bom e você não pode simplesmente consertá-la.
Não. É o código externo que está escrito para o construtor. Isso reproduz a tabela. Em seguida, clico no botão e todos os arquivos de conexão e o núcleo de inicialização para o motor são impressos. Então tudo funciona.
Como eu entendo, é um autogerador que gera o código de autoconexão mais parte do código do kernel. Esta é uma solução interessante.
Ainda não o testei.
Funciona para mim. Mas parece haver um problema com o fechamento de uma fila quando uma parada é acionada. Às vezes a fila permanece. Este é um problema com a detecção de ordens fechadas no código que escrevi. A mesa não tem nada a ver com isso.
1. É por isso que estou perguntando. Se você tem 21 linhas no núcleo, não é bom e você não pode simplesmente consertá-lo.
2. Entendo que é um autogerador que gera o código de autoconexão mais parte do código do kernel. Solução interessante.
1. Exatamente. Um número limitado de elementos pode ser prescrito no construtor. Portanto, uma tabela dinâmica deve consistir de um número limitado de linhas, mas ao mesmo tempo, ser irrestrita. A solução é apenas criar matrizes especiais para parâmetros adicionados e rolar seus valores através das células da tabela.
2. Sim. Constructor cria kernel para motor com base no código que você citou. + imprime os arquivos de conexão. Em seguida, coloco o miolo no motor (DRIVE). Depois disso, o motor pode tocar a GUI desejada. Os arquivos de interface se conectam à EA e começam a interagir com ela.
A fim de não ser infundado, darei finalmente um exemplo do próprio "núcleo". Mais precisamente, trata-se de um arquivo de inicialização. Há vários núcleos.
Deixe-me lembrá-lo que é impresso automaticamente, com base no código KIB. Em seguida, colocado no motor. Além disso, o motor funciona com ele.
Nikolay, vamos falar sobre o assunto. Tomemos a classe CCanvas, por exemplo, com a qual eu já lidei. Assim, retirei dele todas as funções. Tornou-os independentes do invólucro da classe. Como isso é pior agora? Tornou-se mais fácil trabalhar com eles. Eu fiz uma animação usando estas funções. Antes disso, eu quase nunca via animações com esta classe.
Então, por que este invólucro?
Você também está desenhando em uma tela. Você poderia simplesmente chamar uma função específica e desenhar. Mas não. Você embrulha e embrulha e embrulha. Então me explique, por quê?
Sim, porque é mega-confortável. Mas é muito difícil de entender até que se comece a usá-lo por conta própria.
Não sou capaz de pensar de uma maneira que me seja conveniente. Portanto, não é conveniente para mim. Envolver, descrever a orientação dos objetos. Para classificar quando necessário e não necessário.
Fica-se com a impressão de que o próprio OOP fica na frente do mecanismo que supostamente deve servir. Ou seja, o mecanismo deve lutar pela integridade e, portanto, pelo menor número de seus blocos. Mas o OOP força esses blocos a se multiplicarem por qualquer razão. Como resultado, a estrutura dos mecanismos é esfarrapada e eles não funcionam bem. E eles se desenvolvem ainda pior.
Nikolay, comece a criar mega-mecanismos (10 vezes maiores do que a classe Kanvas), e você entenderá onde e como o OOP se torna inconveniente.
Não sei como pensar de uma forma que me deixe à vontade. Portanto, para mim, é desconfortável. Envolvendo-se, retratando a orientação do objeto. Classificando quando necessário e não necessário...
Fica-se com a impressão de que o próprio OOP fica na frente do mecanismo que supostamente deve servir. Ou seja, o mecanismo deve lutar pela integridade e, portanto, pelo menor número de seus blocos. Mas o OOP força esses blocos a se multiplicarem por qualquer razão. Como resultado, a estrutura dos mecanismos é esfarrapada e eles não funcionam bem. E eles se desenvolvem ainda pior.
Nikolay, comece a criar mega-mecanismos (10 vezes maiores do que a classe Kanvas), e você entenderá onde e como o OOP se torna inconveniente.
Suas palavras dizem apenas uma coisa:
...
Nikolai, já lhe ocorreu que seu amor pela OOP não é justificado por quase nada além de razões abstratas?
Digamos, se você estivesse criando mecanismos gigantescos com este OOP, ficaria claro porque você precisa tanto dele. Você justificaria especificamente por que você precisa do OOP. Mas, você cria mecanismos relativamente pequenos. Não há ali código suficiente para tirar conclusões sobre as desvantagens e vantagens desta ou daquela abordagem. Mas você continua falando de OOP de qualquer maneira. Enquanto o OOP é apenas uma ferramenta, e não tem sentido por si só. Isto é, se não houver nenhum mecanismo a ser feito, o OOP não é necessário. Mas se existe um mecanismo, ele deve ser sério o suficiente para exigir o OOP enquanto o cria.
A maioria daqueles que defendem o OOP não fazem nada de sério. Eles só fazem pequenas coisas. Entretanto, sua crença no OOP é inabalável. Outros que fazem mecanismos muito mais sérios são muito menos propensos a gritar sobre a grandeza do OOP. Alguns até falam com críticas (já houve algumas vezes).
Portanto, sua argumentação precisa ser apoiada pela prática, não apenas pela teoria. Eu, por exemplo, posso argumentar sobre os benefícios do OOP no desenvolvimento de GUI com Anatoly, porque podemos comparar soluções e suas nuances na prática. Mas, com você, eu não posso desenvolver meu argumento porque você não o entenderá. Você vai, mas não vai entender (sem ofensa). O anatoly, pelo contrário, pode entendê-lo muito bem. A diferença na experiência de criação de mecanismos globais é a principal razão para o mal-entendido.
SZY. Como praticante, direi o seguinte: A abordagem deve ser tal que maximize o potencial do cérebro de um determinado programador. Encontrei essa abordagem para mim mesmo.