Minha abordagem. O núcleo é o motor. - página 18
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
Não, enquanto estamos discutindo sobre programação casual, eu estou arrastando o cobertor para o OOP, o iniciante do tópico ainda está segurando! Ele escreve que tudo pode ser mantido em sua cabeça - bem, programação casual)))
Core-engine
Programação casual ))))
Programação ocasional :)
Programação ocasional :)
Talvez você esteja certo, eu me lembro do termo - há alguns meses atrás, em outro fórum, um cara se chamou de programador casual, eu até tentei esclarecer o que isso poderia significar, meu conhecimento da palavra casual está associado apenas ao jogo Android - "Zuma", afinal é um programador que programa aleatoriamente - de ocasião em ocasião ))))
O OOP é uma metodologia muito flexível, por isso não tem nenhuma idéia a priori como o conceito de "núcleo". No entanto, o modelo de núcleo em questão aqui pode muito bem ser construído usando o OOP. Portanto, a afirmação não é totalmente correta.
Não, o OOP não tem nada a ver com isso. O núcleo é Unix, nós montamos tudo ao redor do núcleo; a casca é tudo o que é como o Windows, retiramos o que é supérfluo e trabalhamos com o resto. Em geral, trata-se de um sistema operacional.
Programação Cajun :)
Cajual, não se preocupe.
O que me repugna no OOP é o formato rígido do código de escrita. Como você já viu, tenho a tendência de fazer grandes tabelas de dados e acho-as muito práticas. No OOP eu tenho que aderir a um monte de regras, o que pessoalmente acho muito constrangedor.
Em resumo, eu programo com um OOP diferente. O meu próprio. Há poucas regras e muita liberdade. A própria funcionalidade é empilhada em grandes blocos e os dados são organizados em kernels. Eu nem sequer penso especialmente em sua estrutura. Tudo se desenvolve por si só. No nível intuitivo.Peter, essas regras são as que você mesmo precisa. É por isso que eles estão "endurecendo" você. Para que você não faça bagunça acidentalmente e se meta em algo que não deveria fazer. Na verdade, o estilo OOP é "regras da estrada" - é claro, elas restringem o motorista. E em uma vila com três metros - ninguém olha para eles, é mais fácil e rápido (mais eficiente). Entretanto, em uma cidade grande, é o oposto - são as regras de trânsito que permitem as conexões de transporte mais eficientes. É o mesmo com o AOP. São as regras que permitem construir grandes sistemas complexos da maneira mais eficiente.
Em seu sistema - simplesmente ainda não houve nenhuma mudança, é muito limitado no uso e não precisa de modificações. É por isso que você pode mantê-lo em sua cabeça. Tudo bem se o sistema conseguir usuários e precisar de modificações - a falta de controle e de encapsulamento será bastante estressante.
Tudo o mais - sem diferença, OOP e seu estilo (como dito, você também tem estilo de procedimento - também sofre das mesmas falhas - variáveis globais, falta de controle de tipo e assim por diante) são de outra forma próximas.
Em defesa de seu estilo, você precisa provar a única coisa - que manter todo o sistema em uma enorme variedade global com acesso arbitrário é melhor do que dividir o programa em um monte de pequenas partes aninhadas em cadeias de herança com acesso polimórfico, e escondidas por encapsulamento.
A propósito, há pessoas no fórum que não gostam de heranças - acho que elas podem apoiá-lo.
Outra vantagem do uso do OOP, ao contrário do método de Peter. No OOP, o programador não precisa do código fonte da classe base e não precisa entender como ela funciona. Para estender ou alterar a funcionalidade da classe base, é suficiente criar um herdeiro desta classe.
Se você usar o método de Peter, o programador precisa entender todo o código longo, e se não houver código fonte, você terá que escrevê-lo a partir do zero.
Tudo o mais - sem diferença, OOP e seu estilo (como já mencionado, você tem um estilo de procedimento - também sofre dos mesmos inconvenientes - variáveis globais, falta de controle de tipo e assim por diante) estão de outra forma próximos.
eu poderia estar errado, e o googling é muito preguiçoso, mas o estilo de procedimento implica uma completude lógica de um procedimento (função) - "desatarraxá-lo" da fonte e usá-lo em outro código, ou seja, as funções MQL embutidas tomam os dados como parâmetros e retornam o resultado.... e aqui, Piotr caiu sobre os dois pés )))) - O intercâmbio através de variáveis declaradas globalmente reduz a portabilidade do código e permite o rastreamento de bugs difíceis de rastrear ;)
Muito bem. Digamos que estou convencido.
Em princípio, compreendi tudo isso por muito tempo. E eu concordo com isso. Entretanto, ao mesmo tempo, prefiro minha própria abordagem. Por quê?
Há uma razão em particular:
DESENVOLVIMENTO DE PROGRAMAS.
//---------------------------------------
A que velocidade o programa se desenvolverá com o OOP e com minha abordagem? Qual abordagem é mais favorável ao crescimento e à complicação dos mecanismos?
Concluí que minha abordagem + língua nativa no código (60% russo e 40% do inglês), dão um crescimento rápido máximo do programa.
Precisamente este crescimento rápido é o que eu preciso. Não escavar nos detalhes. Não apenas pairando sobre cada linha de código. Não é uma abordagem profissional.
Eu queria que o programa se desenvolvesse rapidamente e se tornasse mais complexo. Esses mecanismos seriam criados para desempenhar as funções a eles atribuídas. Rápido e fácil.
Para que você pudesse acrescentar novas características com algumas linhas de código.
Minha abordagem é superior à do OOP na solução desta tarefa em particular.