Que código OOP pode fazer que o código de procedimento não pode? - página 3
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
Com projetos de pequena escala você pode mostrar que qualquer problema pode ser decomposto em código de procedimento. No entanto, as coisas ficam muito mais difíceis quando se tem vários milhões de bases de códigos de linha com equipes de mais de 100 desenvolvedores, vários analistas de negócios e arquitetos, todos querendo fazer modificações no "modelo" ao mesmo tempo. Nestas circunstâncias, o modelo "empresarial" é geralmente definido em uma ferramenta de projeto como UML e é acessível a toda a equipe.
Só o modelo de negócio contém mais de 5000 classes. A partir deste modelo de negócio existem ferramentas que "geram" classes para o modelo de objeto, as interfaces SQL e as camadas de rede, levando a contagem da classe de base para 15.000 classes.
Para esta discussão, o Id gosta de dividir o argumento procedural vs OOP em três "extensões" que foram adicionadas ao procedural desde os anos 60/1970
1) "Baseado em objetos" é onde objetos e códigos são encapsulados para fazer uma "estrutura" avançada que também pode ter comportamentos
2) "Baseado na classe", é onde os Objetos podem herdar uns dos outros e ser dispostos em hierarquias
3) "Orientação a objetos", onde o usuário pode definir comportamentos "polimórficos" (métodos virtuais ou interfaces) dentro das hierarquias de classes
Há um argumento de que tudo isso pode ser implementado em idiomas de procedimento com esforço suficiente, por exemplo, a maioria dos conjuntos de ferramentas GUI nos anos 80/90 foram criados em c e tinham essas características, mas não são fáceis de implementar pelo codificador casual e não são realmente aplicáveis a essa discussão.
Então, para responder à pergunta, podemos implementar um projeto multi milhão de linhas com mais de 100 desenvolvedores sem usar as 3 características do OOP?
Minha opinião pessoal é que é praticamente impossível entregar um projeto em larga escala sem 1) e 2) porque sem um sistema "baseado em classe" é tão difícil mapear as estruturas de dados e comportamentos do mundo real em código de uma maneira limpa e concisa. E mais ao ponto, à medida que o tamanho de seu projeto é dimensionado, o que começa como um "podemos implementar isso em c" torna-se uma lista interminável de métodos com menos estrutura que se tornam mais difíceis de manter.
Agora os idiomas que entregam apenas 1) e 2) não são idiomas OOP completos. Portanto, devemos considerar se os "métodos polimórficos (virtuais)" são realmente necessários. Isto é um pouco mais um "talvez", ou "às vezes", porque o polimorfismo nem sempre é a ferramenta correta para resolver um problema e pode complicar demais o projeto. Por exemplo, ao modelar algumas estruturas de dados que mapeiam para uma loja de objetos ou banco de dados SQL adicionando comportamentos virtuais pode tornar o mapeamento de dados mais difícil, entretanto, ao definir conjuntos de ferramentas extensíveis ou API's usando uma "interface" ou classe base com "métodos virtuais" é inestimável. Em geral, sou um grande fã do polimorfismo quando usado com parcimônia e no contexto certo.
Já trabalhei em algumas bases de código "C" de vários milhões de linhas e várias outras bases de código C++/Java/C# de vários milhões de linhas, e a maioria das bases de código "C" declina para "modo de manutenção" após 5 anos porque os desenvolvedores têm medo de mudar a arquitetura, pois o código é frágil demais e as modificações muitas vezes causam meses de doloroso re-desenvolvimento e testes. Em geral, os projetos Object Oriented são muito mais resistentes à modificação e refatoração.
"se...então...senão..." declaração deve fazer o trabalho.
se....então...senão não é capaz de codificar métodos "virtuais".
Há várias implementações de "polimorfismo" em "C" e a maioria delas usa vetores de apontadores de funções para manter os mapeamentos necessários. Mais ao ponto esses "vetores de apontadores de função" precisam ser definidos para cada "tipo" que se deseja modelar na "hierarquia". É claro que o "C" não suporta hierarquias diretamente, então você terá que resolver esse problema também.
Se você realmente quer entrar no saco de vermes que são métodos "virtuais" implementados em "C" então você pode desenterrar os toolkits X Windows que estão disponíveis gratuitamente em cada distribuição Linux.
É claro que o Windows tem que ser ligeiramente diferente e usa estruturas extensíveis com ids de mensagem inteira. Isto significa que o comportamento "polimórfico" é implementado por meio de declarações de switch nas ids. (provavelmente a maneira mais suja de fazer isso, mas isso o levará até lá)
Você concorda que o sistema operacional Windows está oferecendo uma boa GUI? Tanto quanto sei, está escrito em linguagem C. Procedural e não OOP.
Você está errado Dirk se você acha que um programa complexo só poderia ser construído com o OOP. Você deveria antes explicar por que é melhor codificá-lo com OOP.
O Kernel do Windows está em "C", mas o Kernel é apenas um pequeno componente da base de código do Windows e grande parte da base de código de nível superior é implementada em C++ com interfaces externas estilo "C" para suportar vários idiomas.
Mesmo os componentes GUI legados do Windows implementam seu próprio "comportamento polimórfico" enrolado manualmente que são efetivamente "OOP" implementado em "C". Por exemplo, quando você recebe um "Handle" de volta de um controle GUI você está obtendo uma estrutura "C" extensível com comportamento polimórfico disponível, este é o OOP apenas envolto em um conjunto feio de sintaxe "C".
Dizer Windows em não OOP porque está escrito em "C" não é totalmente exato.
Não vou construir uma GUI em linguagem processual para provar que você está errado. Mas eu poderia, sem qualquer dúvida.
A propósito, também é fácil codificar códigos ilegíveis e muito mais lentos no OOP, e como você sabe, a Metaquotes Standard Library é uma boa prova disso.
OOP ser muito mais lento que o código de procedimento é um mito completo. A razão pela qual muitos projetos OOP são mais lentos é porque eles são mal concebidos. A sobrecarga de uma chamada de função virtual é muito menor do que você esperaria, especialmente com as arquiteturas atuais de busca de memória de chip que podem olhar para cima e executar em paralelo.
https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/
Citação do link acima: "Mas o custo de uma chamada, qualquer que seja o sabor, é dominado pela avaliação de seus argumentos. Vimos que as chamadas indiretas, seja no estilo C ou nos métodos virtuais C++, são intrinsecamente baratas. Uma chamada para um método virtual não é mais cara do que uma chamada indireta utilizando um membro estruturante (algo->função(arg1,arg2)), portanto considerar a função virtual como incrivelmente lenta é apenas mal informado".
Java pode ser muito mais lento que C++ porque cada pedaço de dados encapsulado deve ser uma classe baseada em pilha para que você obtenha muito mais desreferenciamento de objetos. Entretanto, mesmo Java pode ser exatamente a mesma velocidade que C em loops e operações matemáticas básicas.
Se você comparar C com C# é realmente bastante difícil escrever algum código que é significativamente mais rápido em C vs C#, mesmo quando você inclui algumas das características do OOP.
Se a biblioteca padrão Metaquotes for lenta então será 90% devido ao design das características da biblioteca e terá muito pouco a ver com as características OOP utilizadas.
(Como comparação, a Biblioteca de Modelos Padrão C++ executa 95% de qualquer projeto C já escrito)
...
Obrigado por sua grande contribuição.
Obrigado por sua grande contribuição.
Obrigada, e eu não estava com um estalo em você, só que você é o único que defende o argumento processual :)
Não tenho que me preocupar em desempenhar meu papel de "moderador".
Claro, seria bom ver alguns exemplos do que quer que seja que vocês estejam falando. Conversar/escrever é tudo bem e bom para as pessoas que têm experiência em tudo isso, mas eu sou um visual de mãos sobre o tipo de estudante, por favor poste exemplos.
Estou na cerca para saber se vou ou não continuar aprendendo mql4, mudar para mql5 ou simplesmente ir com outra plataforma.
Obrigado Alain por iniciar esta linha. Este fórum realmente precisa disto.
Você realmente espera que alguém profissional esteja postando uma biblioteca concorrente, exatamente como uma "prova"? ;) Eu poderia postar um link para algo pronto que não pode ser vendido no mercado aqui, mas Alain vai me chutar se eu o fizer ;) Você pode visitar meu perfil e dar uma olhada na foto na parede para ter uma idéia ou me deixar cair uma pm.
Outra plataforma? Você não encontrará nenhuma outra plataforma com um compilador tão poderoso. De jeito nenhum.
@James Cater - que muito obrigado por seus comentários.
Você realmente espera que alguém profissional esteja postando uma biblioteca concorrente, exatamente como uma "prova"? ;) Eu poderia postar um link para algo pronto que não pode ser vendido no mercado aqui, mas o Alain vai me chutar se eu o fizer ;) Você pode visitar meu perfil e dar uma olhada na foto na parede para ter uma idéia ou me deixar cair uma pm.
Outra plataforma? Você não encontrará nenhuma outra plataforma com um compilador tão poderoso. De jeito nenhum.
@James Cater - que muito obrigado por seus comentários.