Sobretaxa para a OLP - página 6
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
mas não funciona :-)
Estou lhe dizendo - tente fazer isso, é um código de lote feroz. A classe instantânea "CFoo: public InterfaceCFoo" deve conter o campo InterfaceCFoo *contexto privado (fazer relação 1:1), criar e excluir via fábrica, delegar todos os métodos e traduzir as referências CFoo* aqui e ali. Isto é "pôr do sol à mão", ou seja, substituir a herança pela delegação, e no local.
Criar através da fábrica e apagar da maneira usual. Se você precisa de delegação é determinado pela forma como o conteúdo da biblioteca deve ser usado: se ela fornece classes que fazem o trabalho por conta própria, então você não precisará delegar nada - basta chamar os métodos de interface.
A propósito, no Android/Java há uma coisa semelhante com as classes de kernel - devido à falta de herança múltipla, é preciso inserir um delegado no objeto e fazer métodos de embalagem para seus métodos. C'est la vie.
Estou lhe dizendo - experimente, é um código de lote feroz. A classe instantânea "CFoo: public InterfaceCFoo" deve conter o campo InterfaceCFoo *contexto privado (fazer relação 1:1), criar e excluir via fábrica, delegar todos os métodos e, ao mesmo tempo, traduzir as referências CFoo* isto<->contexto privado aqui e ali. Isto é "pôr do sol à mão", ou seja, substituir a herança pela delegação, e no local.
E a linguagem, uma pessoa sóbria não consegue entender do que estamos falando sem meio litro. :) E todo esse material do OOP e toda essa alfabetização chinesa é feita para - fazer uma simples troca de dados, que é realizada trivialmente no nível processual...
O próprio OOP não é culpado pela existência de codificadores OOP viciosos. Não há nada de errado com o OOP em geral, você está completamente errado em sua opinião sobre o OOP.
O próprio OOP não é culpado pela existência de codificadores OOP viciosos. Não há nada de errado com o OOP em geral, você está completamente errado em sua opinião sobre o OOP.
Você não conhece sua história.
Proibições repetidas para sabotagem direta. Portanto, não reaja à sua ignorância beligerante.
Em geral, não há nada de errado com o OOP; você está completamente errado em sua opinião sobre o OOP.
Vou lhe dar algumas citações críticas famosas do wiki sobre o OOP de pessoas que, por alguma razão, não são chamadas de ignorantes:
Como uma libertação, citarei algumas famosas citações críticas do wiki sobre o OOP feitas por pessoas que, por alguma razão, não são chamadas de ignorantes:
E todos os três: Stepanov nascido em 1950, Wirth em 1934 e Killea igualmente antigo (seu livro foi publicado em 1998) terão muita vergonha de repeti-lo em 2017.
O que eles disseram foi há tanto tempo que já é embaraçoso de se lembrar. Os compiladores C++ eram pelo menos 2 ordens de grandeza dumber e mais primitivos em otimizações. Na verdade, não havia sequer um traço de otimização ali. Naquela época (muito início dos anos noventa), eu mesmo escrevi muito assembler e pensei de forma semelhante: "C/C+++ é lento".
Não me cabe a mim conduzir links sob a forma de cotações depenadas. Além disso, você já conseguiu mostrar sua extrema estupidez e ignorância agressiva neste tópico.
Renat Fatkhullin:
Mais ainda, você já conseguiu, nesta linha, mostrar sua extrema estupidez e ignorância agressiva.
Vamos resumir. Aqui está minha hipótese principal sobre o OOP: "OOP só faz sentido como um conveniente invólucro de texto ou quando usado minimamente durante a inicialização em tempo de execução..." no post #10.
E aqui está uma opinião fundamentada de um especialista independente com uma opinião semelhante e prova detalhada de nível de código.
http://rainman-rocks.livejournal.com/122876.html
"A conclusão final de tudo isso é a seguinte:
A principal razão para a eficácia da programação orientada a objetos é que ela contém os meios para proporcionar modularidade e declaratividade. É a modularidade e a declaratividade que são as ferramentas que aumentam a eficiência do desenvolvimento - ou seja, "balas de prata como as de prata". É neles que se deve se concentrar ao escolher uma metodologia. Só o OOP não deve ser o objetivo".
Para resumir. Aqui está minha hipótese básica sobre o OOP: "OOP só faz sentido como um conveniente invólucro de texto ou quando usado minimamente na inicialização em tempo de execução..." no post #10.
E aqui está uma opinião fundamentada de um especialista independente com uma opinião semelhante e prova detalhada de nível de código.
http://rainman-rocks.livejournal.com/122876.html
"A conclusão final de tudo isso é a seguinte:
A principal razão para a eficácia da programação orientada a objetos é que ela contém os meios para proporcionar modularidade e declaratividade. É a modularidade e a declaratividade que são as ferramentas que aumentam a eficiência do desenvolvimento - ou seja, "balas de prata como as de prata". É neles que se deve se concentrar ao escolher uma metodologia. O OOP em si não deve ser o objetivo".
Mostre seus projetos implementados pessoalmente para que sua opinião seja aceita pelo menos minimamente. Você nem consegue entender o link citado - é apenas uma ode ao OOP, incluindo a produção.
Todo o software é praticamente mais de 90% escrito no OOP (não mencione bobagens sobre motoristas). Na verdade, é impossível escrever e depois manter um grande projeto sem o OOP. E nenhuma palavra sobre "apenas um invólucro" é aceita quando se trata de negócios. O desenvolvimento de software tem sido um negócio bem estabelecido e testado ao longo do tempo.
Aqueles que reclamam do OOP sem entender não estão cientes do que os compiladores C++ modernos fazem. Muitas vezes não sobra nada do OOP no código final. Estou falando de C++, é claro.
Mostre seus projetos realizados pessoalmente para que sua opinião seja aceita pelo menos minimamente. Você nem consegue entender o link citado - é apenas uma ode ao OOP, incluindo a conclusão.
Deixe-me dar-lhe mais uma citação sobre a idéia principal deste artigo para que não haja dúvidas sobre o que ele diz:
"Assim, o OOP, ao mesmo tempo em que procura substituir a programação estruturada-processada, acabou voltando a quase a mesma coisa, mas apenas em envoltórios fantasiosos. Surge alguma questão: havia algum sentido na manobra...".
Desculpe, mas não entendo a lógica e a relação de causa e efeito - por que você precisa de qualquer projeto realizado para que a opinião de uma pessoa seja levada em consideração ao mínimo. Normalmente, em uma discussão civilizada, o raciocínio e a validade razoável do próprio parecer apresentado é suficiente.
Caso contrário, chegamos à conclusão absurda de que se uma pessoa implementou um projeto, então todas as suas declarações subsequentes devem ser aceitas por todos inicialmente, embora na verdade possa não ser tudo fácil com o raciocínio ou mesmo contradizer a opinião de outros profissionais que também implementaram projetos.
Mais uma vez, não é muito modesto vangloriar-se de algo, pois isso é ruim para o carma.
Ou seja, não há projetos, portanto, nenhuma experiência.
Ao mesmo tempo, você não esquece a experiência, tentando retirar os dizeres mais antigos de pessoas que já tiveram experiência(em termos de seu tempo). Como você não tem sua própria experiência, não percebe que as declarações arrancadas não funcionaram há muito tempo. Eles não funcionavam e eram apenas ilusões peculiares daquela época. Essas ilusões já são embaraçosas de se lembrar.
Além disso, você não entende realmente a essência do que está escrito nos links citados. Você pega palavras e as interpreta mal, embora diga "OOP é melhor que muletas (e muletas são uma tentativa de imitar OOP sem OOP) e deve ser usado".