Programação OOP vs procedimento - página 39

 
Andrei:

A classe tem apenas variáveis internas e nenhuma entrada ou saída. Onde você já viu o uso na programação de tal objeto que de nenhuma maneira entra em contato com o mundo exterior e ferve em seu próprio suco?


Por que vocês estão discutindo sobre algo que ainda não viram? É criado um construtor de classes e ele pode obter qualquer número de parâmetros. Diferentes classes de crianças podem ter conjuntos de parâmetros completamente diferentes em seus construtores. Você pode simplesmente escrever métodos para definir parâmetros.

 
СанСаныч Фоменко:

1. Esta é a principal resposta à necessidade do OOP.

2. É uma questão de experiência em equipe. Eu escrevi tudo o que precisava. Há alguns anos decidi escrever mais um pouco - tudo lê, sem problemas.


De suas respostas eu entendi uma coisa: OOP é um certo padrão que introduz a disciplina da programação, introduz uniformidade e sobre esta base, menos erros inicialmente e, mais importante e mais importante, reduz os problemas de modificação em princípio. Mas o mesmo resultado foi obtido com a observância cuidadosa dos GOSTs, estágios de desenvolvimento, documentação.


Quantas vezes devo dizer-lhes a mesma coisa? O OOP não é apenas um meio de estruturação de códigos; ele também contém mecanismos que estão ausentes em sua programação processual.

Este talvez seja o caso quando uma pessoa não viu montanhas, não vai entender, mesmo que você lhe diga isso.

 
Реter Konow:

Eu pessoalmente me esforço pela versatilidade nas soluções. Isto requer "emendas" de funções similares em um único bloco sem aumentar o tamanho do código. Ele aumenta a eficiência do mecanismo e não há necessidade de sobrecarga e divisão. Você só tem que usar um pouco seu cérebro - isso é tudo).

Ou seja, existiam duas funções de 20 linhas cada uma. Ambos realizam ações similares ou resolvem tarefas similares. Meu objetivo é fazer uma função que faça o trabalho de ambos com não mais do que 20 linhas de código. É assim que eu crio blocos.


Há quanto tempo você está por cima desta sua biblioteca?

 

Por uma questão de alegria - R está escrito em um modo absolutamente nojento "tudo em uma lata de lixo, sem diferenciação de acesso". Uma abordagem old-school de vinte anos atrás, sem áreas de visibilidade, proteção ou multisessão. Escrevo como se eu fosse o único. Sim, o projeto nasceu sob uma pessoa por desenvolvedores não-profissionais. Ela deve ser reescrita do zero. Pelo menos uma vez.

Tive a idéia de fazer uma interface normal em R a partir da MQL5, mas depois de me aprofundar nela, decidi imediatamente não integrá-la. O sistema é categoricamente incapaz de proteger os dados e as sessões.

Até que um programador trabalhe em equipes normais de desenvolvimento com requisitos rigorosos (batendo as mãos por pelo menos alguns anos) ele não se tornará um desenvolvedor em um sentido normal. Agarramos nossas cabeças 90% do tempo quando olhamos para trabalhos de teste quando consideramos candidatos. Um horror total em toda a indústria de desenvolvimento.

Portanto, mais uma vez - os oponentes do OOP estão exibindo algum tipo de bufonaria aqui.

Desculpe novamente.

 
СанСаныч Фоменко:

Uau!

Eu estava me perguntando: existe alguma outra maneira na programação de hoje para confundir um problema de nível de ovo de uma maneira mais fria?

Vá até um carro parado em um engarrafamento, veja como ele é montado e diga ao motorista "há alguma maneira de confundir melhor o problema, ande cem metros aqui".

Como mostra minha experiência, tais "problemas confusos" são muito mais fáceis de entender do que os EAs "sem problemas" feitos por cópia de um único modelo com todas as variáveis globais.

 
Dmitry Fedoseev:

E por que você está especulando aqui sobre algo que você ainda não viu? É criado um construtor de classes e ele pode obter qualquer número de parâmetros.

Leia com atenção, era sobre a classe, não sobre o construtor da classe.

Além disso, você novamente sugere fazer o trabalho de um macaco - plantar um jardim em um terreno quando podemos ter acesso aos parâmetros sem fazer QUALQUER coisa em caso de variáveis externas ou passá-las diretamente sem nenhuma dor de cabeça desnecessária com construtores-destrutores e todos os vazamentos de memória que isso acarreta.

 
СанСаныч Фоменко:

MeuOnInit() parece mais ou menos o mesmo - uma dúzia de linhas...

Então?

Por motivos, em TODOS os meus EAs há dez linhas (se não contarmos as inclusões e comentários).

#include <MyLib\DebugOrRelease\DebugSupport.mqh>
#include <MyLib\Factories\ForTrade\EURGBP\B1H2C20T2_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B2H2C20T4_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B3H2C20T2_0001_EPF.mq5>

// Объявляем фабрики частей эксперта.
CB1H2C20T2_0001_EPF epfFact_0;
CB2H2C20T4_0001_EPF epfFact_1;
CB3H2C20T2_0001_EPF epfFact_2;

// Объявляем функцию получения указателя на фабрику.
CEAPartsFactoryT* CEAPartsFactoryT::GetAdvisorsPartsFactory(uint uiFactIdx = 0)
{
   if(uiFactIdx == 0) return(GetPointer(epfFact_0)); 
   if(uiFactIdx == 1) return(GetPointer(epfFact_1)); 
   if(uiFactIdx == 2) return(GetPointer(epfFact_2)); 
   return(NULL); 
};

#include <MyLib\TSTemplate\ExpertAdvisorT.mq5>

Em nosso caso, existem três TS completamente diferentes em uma EA. Todos eles trabalham simultaneamente, sem interferir uns com os outros.

TCs adicionais podem ser adicionados declarando a fábrica apropriada, e adicionando código devolvendo-a a uma função.

Mas a verdadeira questão não é se há muito poucas ou muitas linhas de código. A questão é como eles são fáceis de manter e modificar, se necessário.

SanSanych, você pode descobrir facilmente o arquivo de tabela fornecido por Peter? E modificá-lo facilmente ? Bem, então você, como Peter - não precisa de OOP.

 
Реter Konow:
OOP é um método para separar, embrulhar e esconder partes de um mecanismo. Se isso é necessário ou não, cabe ao desenvolvedor decidir. Não tem nada a ver com o aumento da eficiência do mecanismo. Ele estrutura a maneira de pensar, sim. Não se sabe se ele estrutura corretamente ou não. Se é necessário depende de uma pessoa em particular, imho.

Exatamente. Esta é a essência do encapsulamento.

Há também a herança e o polimorfismo.

 
Реter Konow:
O OOP é um método de separar, embrulhar e esconder partes de um mecanismo. Se isso é necessário depende do indivíduo. imho.

Exatamente, depende do indivíduo. Por que um programador, que não está sofrendo de esquizofrenia, esconderia estrondosamente o acesso a alguma parte de seu próprio código que ele mesmo está depurando? Você não prefere amarrar suas próprias mãos? :)

 
Renat Fatkhullin:

Até que um programador tenha trabalhado em equipes normais de desenvolvimento com requisitos rígidos (mãos atadas no mínimo por alguns anos), ele não se tornará um desenvolvedor no sentido normal. Agarramos nossas cabeças 90% do tempo quando olhamos para trabalhos de teste quando consideramos candidatos. Um horror total em toda a indústria de desenvolvimento.

Pergunto-me em que se manifesta este "horror".

Posso supor que tenha a ver com o uso do OOP, pois na programação de procedimentos a principal atenção é dada à lógica do trabalho do algoritmo e não a todos os tipos de complementos externos do OOP, com os quais é muito fácil construir uma floresta de qualquer obtusidade.

Razão: