Conversando sobre a OLP no salão - página 11
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
A quantidade de gestos no OOP não pode ser menor em princípio, porque todas essas interfaces são despesas gerais adicionais, o que muitas vezes excede o custo de escrever a própria lógica. E isto apesar de qualquer função já ter uma interface, ou seja, é proposto construir outro jardim, o que é essencialmente sem sentido.
Ao mesmo tempo, qualquer mudança no código, tanto na interface quanto na função, torna-se muito mais complicada, já que uma está viciada na outra, o que significa que temos pelo menos um aumento quadrático no número possível de bugs e na intensidade de trabalho... É meio óbvio, não é?
A quantidade de gestos no OOP não pode ser menor em princípio, porque todas essas interfaces são despesas gerais adicionais, o que muitas vezes excede o custo de escrever a própria lógica. E isto apesar do fato de que qualquer função já tem uma interface, ou seja, temos que fazer mais uma cobertura que é essencialmente inútil.
Neste caso, qualquer mudança de código tanto na interface quanto na função se torna muito mais complicada, pois uma está viciada na outra, ou seja, temos pelo menos um aumento quadrático de possíveis bugs e de mão-de-obra intensiva... É meio óbvio, não é?
Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais
Conversando sobre o OOP no quintal
fxsaber, 2018.01.14 11:35
A própria programação é um caso especial de produção. A abordagem do OOP é uma abordagem de princípio para produzir qualquer coisa. Portanto, falar sobre programação é muito estreito. O OOP foi aplicado com sucesso ANTES de aparecer na programação.
A história da indústria chegou à PRODUÇÃO orientada a objetos como a próxima etapa da esteira transportadora. Portanto, falar sobre a programação OO é uma visão estreita. Como falar de botas de costura OO. Estamos falando de abordagens algorítmicas para a organização de qualquer produção, incluindo, como um caso muito especial, a criação de software.
A produção do OOP provou ser competitivamente superior às linhas de montagem convencionais. Há um planejamento de produção a curto prazo, quando é necessário fazê-la funcionar agora. E há o longo prazo - quando você coloca muito "extra" no momento, mas essa base é propícia para simplesmente aumentar a produção. Mais uma vez, não se trata de programação, mas de abordagens gerais na criação da produção.
As abordagens OOP podem ser vistas mesmo em instituições de poder modernas.
O terminal é uma classe em relação ao seu código. Com que freqüência você precisa mudar algo no código do terminal?
Este exemplo é incorreto. Estamos falando de interfaces dentro do seu programa...
A história da indústria chegou à PRODUÇÃO orientada a objetos como o próximo passo na esteira transportadora.
A programação OO também tem suas tubulações de processamento e o OOP introduz outra camada de abstração que só aumenta a sobrecarga de cada transportador individual e de toda a produção.
A programação OO também tem seus próprios transportadores de processamento, e o OOP introduz outro nível de abstração que só aumenta a sobrecarga de cada transportador individual e de toda a produção.
Você é estúpido, infelizmente. Você é informado sobre a história da indústria e sobre o OOP como uma das etapas dessa história, que desempenhou um papel enorme em todas as coisas materiais (e não apenas) ao seu redor. E você continua falando de um caso especial de programação.
Ignorância da História do Desenvolvimento Humano. Você não deixará um rastro na memória de seus descendentes diretos.
Você é contado sobre a história da indústria e sobre o OOP como uma etapa dessa história, que desempenhou um enorme papel em todo o material (e não apenas) ao seu redor.
Sua ingênua tentativa de arrastar a OLP para a história da indústria é divertida, mas infelizmente analfabeta.
Este exemplo é incorreto. Estamos falando de interfaces dentro do seu programa...
Por que é "incorreto"?
Como um programa é diferente de TODOS os softwares rodando em um computador?
Afinal, é a mesma série de instruções e conjuntos de dados como em qualquer programa de usuário. Por que é incorreto - aqui ou ali, uma parte do software não tem acesso a outra parte do software a não ser através de protocolos de intercâmbio estabelecidos ?
Tudo bem, se você programar seriamente - mais cedo ou mais tarde você chegará à necessidade de diferenciação dos direitos de acesso.
Eu também, nos dias em que eu passava do modo real para o seguro, odiava não poder acessar nenhum endereço de memória física. Até fiz torções com um controlador DMA que copiava dados da área do sistema protegido para a minha (embora fosse bastante difícil perceber o que era copiado ali, por isso não o fiz)... Na minha juventude fiquei indignado - como poderia não ter acesso direto - foi quase uma violação dos meus direitos... E no programa para me permitir não ter acesso a algo ????
Bem, como adquiri experiência, muitas vezes descobri que a diferenciação dos direitos de acesso é uma vantagem para o próprio programador, porque muitas vezes me poupava de cometer erros em módulos escritos. Você tem uma classe, quer usá-la, e não tem acesso a alguns dados... Você está indignado, como poderia ser, você começa a olhar para isso... e oops... Há coisas que precisam ser levadas em conta e os dados não podem ser acessados diretamente, há "caminhos indiretos", a arquitetura do sistema é tal que, ao acessá-los diretamente, posso obter dados inválidos. Mas também posso obter dados válidos - tudo depende do ponto no tempo. E tal erro é muito difícil de detectar.
Aqui, a questão mais simples é acessar dados em um cache. Se você precisa dos dados em cache e os acessa diretamente - você tem certeza de que obterá os dados corretos? Na abordagem processual sem diferenciação - você tem que entender quando pode usá-la, quando não pode, quando os dados são válidos, quando eles não são... Na abordagem OOP - tudo é muito simples, você não tem acesso aos dados do cache, você só pode chamar a função, que retorna os dados necessários, e se for inválido, ele vai buscar dados válidos. É "mais complicado"? Agora imagine, que você use este cache um ano depois de escrevê-lo. Quando você tiver esquecido completamente os princípios de atualização do cache e definição de validade. Na OOP-aproximação você não se importa. A função de classe lhe proporcionará tudo. Mas na abordagem funcional - você tem que lembrar em detalhes, quando e como o cache é atualizado, quando os dados nele contidos são válidos e quando não são.
Este exemplo é incorreto. Estamos falando de interfaces dentro do seu programa...
O terminal é uma classe em relação ao seu código. Com que freqüência você precisa mudar algo no código do terminal que está escondido de você e que só é fornecido com métodos públicos - funções para implementar seus programas.
+++ )))
O terminal é uma classe em relação ao seu código. Com que freqüência você precisa mudar algo no código do terminalque está escondido de você, e apenas métodos públicos - funções para implementação de seus programas são fornecidas.
Tal necessidade surge regularmente. É apenas desejável que os desenvolvedores façam isso.
Um exemplo simples. Por alguma razão, os desenvolvedores não consideraram necessário fornecer uma grade de coordenadas horizontal para gráficos indicadores. E, é claro, eles não forneceram um método apropriado para isso).