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
Sim, estas unidades têm ambas. Mas confie em mim - eles são comprimidos ao máximo e versáteis, porque resolvem uma ampla gama de problemas.
Se não houver muitas opções, você pode se safar com "ses" e "swipes".
Por que ninguém decidiu argumentar sobre "programação procedural com apontadores de funções versus programação procedural sem apontadores de funções"?
Se não houver muitas opções, você pode se dar bem com os ifs e swipes.
Реter Konow:
1. Дело в работе которую нужно провести чтобы сжать в коде решения огромного количества задач.
2. O objetivo é universalizar o código, no qual quaisquer técnicas de sintaxe e conchas adicionais são simplesmente destrutivas. É um trabalho duro, mas se livra de tudo que é supérfluo e permite que você evolua o tempo todo alcançando novas alturas.
1. Por que fazer o trabalho quando você pode torná-lo fácil e simples? Por que dificultar quando você pode facilitar as coisas?
2. Se você usa OOP, a universalização não é destrutiva, mas se torna uma possibilidade natural que não sobrecarrega nada.
1. Por que fazer o trabalho quando ele pode ser feito de forma fácil e fácil? Por que fazer algo que pode ser feito facilmente, quando é difícil?
2. Se você usa OOP, então a universalização não é ruinosa, mas se torna uma possibilidade natural que não sobrecarrega nada.
Podemos continuar com este argumento por muito tempo. Utilizando o exemplo de uma tarefa de 100 trilhas, mostrei minha atitude em relação a este método de solução. Acredito que tarefas estúpidas não devem ser resolvidas, mas sim consertadas. Se o OOP ajuda aqueles que são mais fracos na definição correta das tarefas e na sua resolução eficaz - que continue ajudando-os. Mas para as pessoas que otimizam tarefas antes de começar a resolvê-las, o OOP pode simplesmente não ser necessário.
Poderíamos continuar com este argumento. Utilizando o exemplo de uma tarefa de 100 trilhas, mostrei minha atitude em relação a este método de solução. Acredito que tarefas estúpidas não devem ser resolvidas, mas sim consertadas. Se o OOP ajuda aqueles que são mais fracos em levantar e resolver as tarefas corretamente, deixe que ele os ajude. Mas para as pessoas que otimizam tarefas antes de começar a resolvê-las, o OOP pode simplesmente não ser necessário.
Você não codificou muito (provavelmente), o OOP é como uma lufada de ar.
A maioria das pessoas não codifica por interesse ou autodesenvolvimento, é seu trabalho, e é o resultado que conta.
Não é tão conveniente, mas em termos de capacidade de velocidade, você pode passar por isso apenas com indicações.
E a conveniência é um conceito relativo.
Dmitry, é claro, usando o OOP reduz um pouco o desempenho. Mas são frações de um por cento.
Mas como o OOP aumenta o desempenho de um programador!
Aqui está um pequeno exemplo de um dos meus projetos, ele é cortado para percepção, mas na verdade há muitas outras coisas levadas em conta.
Por exemplo, tomemos .NET, pois todas as API's consistem em classes.
Eu gosto muito do paradigma .NET. A propósito, existe um grande terminal cAlgo, você pode escrever diretamente no Visual Studio em C#
Dimitri, é claro, o uso de OOP reduz um pouco o desempenho. Mas são frações de um por cento.
Se o número de variantes for pequeno, ele irá desacelerá-lo, mas se houver muitas variantes, será uma vantagem.
O que é mais importante, o número de variantes no OOP não afeta o desempenho. E na programação de procedimentos, há um teto sobre sua cabeça.
Bem, você fez uma bagunça...
É claro que qualquer tarefa pode ser resolvida tanto no estilo OOP, com alocação de interfaces, construção de hierarquia de herança, declaração de funções virtuais, como em puro estilo procedimental - você pode até mesmo colar tudo em uma enorme função.
A questão está na conveniência e eficiência do apoio.
Em MT - o lugar mais apropriado para o OOP é o sistema de pedidos. Pessoalmente, tenho interfaces virtuais para "posição" e "componentes de posição". "Posição" é um conjunto de ordens em MT4 ou um conjunto de posições em MT5. "Posição componente" é um pedido individual ou uma posição MT5 individual (hedge ou netting).
Aqui está o arquivo de interface real(Retag Konow, você pode apreciar o número de comentários em comparação com a quantidade de código, e eu os adiciono periodicamente lá quando encontro que não me lembro de algumas sutilezas. Por exemplo, eu esqueço regularmente quais objetos reais constituem um "componente de posição". Só não preciso lembrar - o Expert Advisor trabalha com componentes de acordo com a interface, e o que está por trás dessa interface na realidade não importa. Mas, eu tenho que voltar a ele durante a modificação - é por isso que eu preciso do primeiro comentário neste arquivo com muita freqüência):
O arquivo para a interface do componente comercial é o seguinte (eu já o dei acima, mas vou repeti-lo:
De acordo com estas interfaces - tenho o sistema de pedidos MT4 e MT5 implementado tanto para pedidos reais como para pedidos históricos.
O Expert Advisor que solicita uma posição recebe esta interface e não precisa levar em conta a diferença entre as ordens MT4 e MT5. E se um novo tipo de pedido for adicionado ou a ordem de trabalho com eles for alterada - nada mudará para o Expert Advisor, apenas a nova classe de tipo de pedido será adicionada, e ele também suportará esta interface.
O sistema fazia muito sentido quando as contas cobertas foram introduzidas. Os especialistas não mudaram em nada.
Reg Konow, como você lida com a diferença nos tipos de pedidos em MT4 e MT5 ?
Se um novo tipo de conta for introduzido (além de hedge e netting) - quais mudanças precisarão ser feitas, e no mesmo lugar ?
Minha opinião é que se você se lembra de todo seu código à letra, e pode facilmente dizer por que esta ou aquela linha em seu código foi escrita há um ano - então é verdade, todos estes aperfeiçoamentos do OOP são apenas gestos desnecessários.
OOP é necessário exatamente quando você não se lembra de tudo ao modificar o código - OOP permite isolar blocos uns dos outros, limitar o conjunto de entidades disponíveis em um determinado momento a um determinado lugar no programa.
Bem, você fez uma bagunça...
1. É claro que qualquer tarefa pode ser resolvida tanto no estilo OOP, com alocação de interfaces, construção de hierarquia de herança, declaração de funções virtuais, como em puro estilo processual - podemos até mesmo colocar tudo em uma enorme função.
A questão está na conveniência e eficiência do apoio.
2. Em MT - o lugar mais apropriado para o OOP é o sistema de pedidos. Pessoalmente, eu tenho interfaces virtuais "posições" e "componentes de posição". "Posição" é um conjunto de ordens em MT4 ou um conjunto de posições em MT5. "Componente de posição" é um pedido individual ou uma posição MT5 individual (hedged ou netting).
3. Aqui está o arquivo de interface real(Retag Konow, você pode apreciar o número de comentários em comparação com a quantidade de código, e eu os adiciono periodicamente lá quando encontro que não me lembro de algumas sutilezas. Por exemplo, eu esqueço regularmente quais objetos reais constituem um "componente de posição". Só não preciso lembrar - o Expert Advisor trabalha com componentes de acordo com a interface, e o que está por trás dessa interface na realidade não importa. Mas, eu tenho que voltar a ele durante a modificação - é por isso que eu preciso do primeiro comentário neste arquivo com muita freqüência):
O arquivo para a interface do componente comercial é o seguinte (eu já o dei acima, mas vou repeti-lo:
De acordo com estas interfaces - tenho o sistema de pedidos MT4 e MT5 implementado tanto para pedidos reais como para pedidos históricos.
O Expert Advisor que solicita uma posição recebe esta interface e não precisa levar em conta a diferença entre as ordens MT4 e MT5. E se um novo tipo de pedido for adicionado ou a ordem de trabalho com eles for alterada - nada mudará para o Expert Advisor, apenas um novo tipo de pedido será adicionado, e ele também suportará esta interface.
O sistema provou ser muito razoável, quando as contas de cobertura foram introduzidas. Os especialistas não mudaram em nada em relação a isso.
4. Reg Konow, como você lida com a diferença nos tipos de pedidos em MT4 e MT5 ?
Se um novo tipo de conta for introduzido (além de hedge e netting) - quais mudanças precisarão ser feitas, e no mesmo lugar ?
Eu acho que se você se lembrar de todo seu código à letra, e puder facilmente dizer por que esta ou aquela linha foi escrita em seu código há um ano - então todos estes aperfeiçoamentos do OOP são apenas gestos desnecessários.
OOP é necessário precisamente quando você não se lembra de tudo ao modificar o código - OOP permite isolar blocos uns dos outros para limitar o conjunto de entidades disponíveis em um determinado momento a um determinado lugar no programa.
1. 1. eu concordo plenamente. A única diferença está na eficácia de resolver tarefas de uma forma ou de outra.
2. Eu não trabalhei realmente com o sistema de pedidos e não consigo ver nenhum problema técnico em sua construção. Talvez haja, mas precisamos de uma tarefa concreta e então ficará claro como posso resolvê-la eficazmente sem o OOP.
3. Do meu ponto de vista, a amostra de código dada é simplesmente horrível do ponto de vista da legibilidade. Não é à toa que são necessários tantos comentários e por que você esquece seu conteúdo. Desculpe, mas essa é a minha primeira impressão subjetiva. É simplesmente assustador.
Aqui está um exemplo de legibilidade do meu código - a função que define a cor de um item de controle:
Como você pode ver, os comentários são quase desnecessários aqui. Todo meu código está escrito neste estilo. Portanto, eu o conheço perfeitamente bem e o lembro não importa o tamanho.
Na minha opinião, há algum defeito em seu sistema de solução de problemas. O problema em si deve ser cristalino e preciso e, portanto, sua solução também. Se a solução estiver nublada e definida pelas palavras "O sistema provou ser muito razoável" (como pode ser razoável em 270 Kb de código?!), isso significa que o autor tem uma compreensão grosseira de como seu sistema funciona. E são terríveis artifícios de sintaxe e entidades desnecessárias na solução que o impedem de compreendê-la até o fim.
Para que uma solução seja eficaz, as entidades desnecessárias devem ser cortadas, e o problema deve ser visto de forma perfeitamente clara.