Conversando sobre a OLP no salão - página 10
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 há necessidade de impor, mas é óbvio que em uma forma processual a lógica do código já é visível sem gestos extras, e cada gesto de um programador contratado custa uma taxa ao empregador. Portanto, se um empregador for inteligente, ele não será enganado pelo OOP, mas um programador inteligente pode distorcer uma história sobre o OOP progressivo para obter mais dinheiro dele, aproveitando sua baixa alfabetização. :)
Ha!
Há uma lógica de "sem esforço extra" para se locomover a pé, mas por alguma razão todos querem pegar transporte. Chega ao ponto da idiotice - eles entram num carro, dirigem dois quilômetros até um centro de fitness, e depois "dão vento" cinco quilômetros em uma esteira.
Falando em programação, no DOS é criada uma janela simplesmente escrevendo-a em um buffer de vídeo. Mas para criar uma janela simples no Windows - você precisa registrar uma classe de janela, criá-la e executar um loop de processamento de mensagens - mas por alguma razão, todos fazem estes "passos extras".
Assim é aqui. o O OOP - é escolhido não pela "progressividade", mas pelos benefícios que esta metodologia proporciona, e porque, em última análise, é mais barato para o empregador. Porque tendo escrito algo em estilo processual, você não pode mantê-lo com a mesma eficiência que foi escrito em estilo OOP.
Uma boa ilustração - código de Peter Konov - por um lado, um código orientado para procedimentos bastante normais, mas por outro lado, para trabalhar com ele você deve ter sempre em mente um monte de informações sobre a estrutura do sistema, que pessoalmente não vou empreender tal tarefa nem mesmo por muito dinheiro. Ao mesmo tempo, a SB escrita no estilo OOP é muito fácil de manter e de mudar. A arquitetura dos objetos no padrão TC da Biblioteca Padrão é muito mais intrincada do que no código de Peter, porém é muito mais fácil de entender e modificar.
Toda a conversa sobre "um estilo de procedimento sem trabalho extra" só chega ao ponto em que é preciso escrever uma estrutura realmente complexa, e especialmente fazer modificações nela. É por isso que o OOP é tão amplamente utilizado - é mais fácil para os programadores, e mais barato para os clientes. Embora, para fazer algo bastante simples nele, seja necessário "trabalho extra". Simplesmente, ninguém precisa deste "simples", todos precisam deste "complexo", o que é melhor fazer com o uso do OOP.
P.S. E eu ainda não entendo, como você (vamos falar sobre "Você") propõe limitar o acesso às funções, que não devem ser usadas em nenhum lugar sem modificadores de acesso OOP?
George Merts:
Porque se você escrever algo em estilo processual, não será capaz de mantê-lo com a mesma eficiência que algo escrito em estilo OOP.
P.S. E eu ainda não entendo, como você (vamos falar sobre "você") propõe limitar o acesso às funções, que não devem ser usadas em nenhum lugar sem modificadores de acesso OOP ?Não, não. É exatamente o contrário.
É apenas o código OOPeshe que é difícil de manter e modificar, pois há muitas voltas e reviravoltas nele que mais tarde é mais fácil escrever o código mais uma vez. De fato, diz-se que o objetivo do OOP é esconder a lógica, por isso eles a esconderam, e se de repente for necessário descobri-la, este é um serviço com custo adicional.
A função Wrapper permite esconder funções internas, mas se de repente você tiver vontade de adicionar esta função interna, você pode escondê-la em uma DLL, ou código fonte em um arquivo separado, e o arquivo no diretório mais distante, de modo que mesmo que você tente não será encontrado, talvez haja mais opções para programadores especialmente furiosos. :)
Não, não é. É exatamente o contrário.
O código OOP é exatamente o mesmo difícil de manter e modificar, porque a lógica lá está escondida com muitos truques diferentes, que depois é mais fácil reescrever o código. De fato, diz-se que o objetivo do OOP é esconder a lógica, por isso eles a esconderam, e se de repente for necessário descobri-la, este é um serviço com custo adicional.
A função Wrapper permite esconder as funções internas, mas se de repente você quiser adicionar esta função interna para qualquer coisa, você pode escondê-la em uma DLL, ou código fonte em um arquivo separado, e o arquivo no diretório mais distante, para que na melhor das hipóteses não possa ser encontrado, talvez haja opções para programadores particularmente enfurecidos. :)
Por que seria "difícil modificar" se a lógica está oculta? É por isso que a lógica está oculta, para impedir que você modifique qualquer coisa onde não possa ser feita.
É apenas na abordagem processual que você quer mudar alguma coisa, mudou-a, e então você não entende por que não funciona (ou pior - às vezes você recebe erros incompreensíveis). E na abordagem OOP você quer mudar isso - e não tem acesso aos internos de classe. E se não há acesso, isso significa que é feito por uma razão, há algo complicado lá, algumas condições implícitas de uso. Respectivamente, se você quiser mudar alguma coisa, você pode pegar essa mesma classe, herdar sua própria classe dela, e mudar ali o que você precisa, uma vez que você já tem acesso aos métodos de proteção na descendência.
E mesmo que você o herde, você pode tropeçar em um método ou campo privado que não está disponível mesmo no descendente, e mais uma vez, por uma razão, isso significa que este campo não se destina a ser mudado mesmo no descendente.
Falando em "esconder em DLL" - o problema é que você só pode esconder TUDO em uma DLL. Não faz parte do objeto. E é para isso que serve o modificador de acesso, para esconder apenas parte do objeto. É por isso que tudo é concebido - para permitir que o programador em cada lugar do programa tenha acesso apenas ao que ele precisa, e nada "de cima" - isto permite não ter medo de que ele possa mudar acidentalmente não o que ele precisa, mas pode mudar a peça, que é permissível para modificação. Qual é então o objetivo da DLL? Abra o código DLL - então o código inteiro é aberto, não as partes. Fechado - mais uma vez, todo o acesso está fechado.
Não sei como limitar o acesso em estilo processual sem utilizar as seções públicas e privadas protegidas. E esta restrição me ajuda muito.
Por que seria "difícil modificar" se a lógica está escondida? A lógica está escondida para que não se possa modificar nada onde não se pode.
É apenas na abordagem processual que você quer mudar alguma coisa, mudou-a, e então você não entende por que não funciona (ou pior - às vezes você recebe erros incompreensíveis). E na abordagem OOP você quer mudar isso - e não tem acesso aos internos de classe. E se não há acesso, isso significa que é feito por uma razão, há algo complicado lá, algumas condições implícitas de uso. Respectivamente, se você quiser mudar alguma coisa, você pode pegar essa mesma classe, herdar sua própria classe dela, e mudar ali o que você precisa, uma vez que você já tem acesso aos métodos de proteção na descendência.
E mesmo que você o herde, você pode tropeçar em um método ou campo privado que não está disponível mesmo no descendente, e mais uma vez, por uma razão, isso significa que este campo não se destina a ser mudado mesmo no descendente.
Falando em "esconder em DLL" - o problema é que você só pode esconder TUDO em uma DLL. Não é uma parte do objeto. E é para isso que serve o modificador de acesso, para esconder apenas parte do objeto. É por isso que tudo é concebido - para permitir que o programador em cada lugar do programa tenha acesso apenas ao que ele precisa, e nada "de cima" - isto permite não ter medo de que ele possa mudar acidentalmente não o que ele precisa, mas pode mudar a peça, que é permissível para modificação. Qual é então o objetivo da DLL? Abra o código DLL - então o código inteiro é aberto, não as partes. Feche-o - novamente, todo o acesso está fechado.
Eu não sei como você pode limitar o acesso em estilo processual sem usar seções públicas protegidas por privados. E esta restrição me ajuda muito.
George, você está batendo o tambor novamente )))) Isto não faz sentido.
Georges, você está batendo no mato de novo )))) Não faz nenhum sentido.
Talvez, talvez.
Mas você é um Casanova em meio período... E eu sou um tutor em meio período. Vejo que "o cliente não está perdido". Por isso, continuo explicando. Como "deformidade profissional".
Talvez, talvez.
Mas você é o Casanova em meio período... E eu sou um tutor em meio período. Vejo que "o cliente não está perdido". Por isso, continuo me explicando. Como "deformidade profissional".
Já estou farto do Casanovas. Você mesmo inventou um conto de fadas e acreditou nele) como uma criança acredita no Pai Natal, pelo amor de Deus).
Não há necessidade de impor isso, mas é óbvio que na forma processual a lógica do código já é vista sem gestos extras, e cada gesto de um programador contratado custa dinheiro ao empregador.
O número de gestos no código de procedimento acima precisará de mais se for necessário fazer mudanças.
É possível escrever código sem funções (procedimentos). Mas a codificação acabou deixando de ser escrita através do "despejo de concreto" e começou a construir a partir de "tijolos". Daí surgiu a programação de procedimentos.
O OOP é mais um passo para decompor o trabalho geral em componentes mais simples.
A divisão do trabalho e, como conseqüência, a estetização da produção de qualquer coisa criou a revolução industrial, que levou à industrialização da humanidade.
Feito à mão é "código de escrita sem procedimentos".
Transportador é "escrita de código de procedimento", onde muitos elementos do transportador são dependentes dos outros. Ou seja, mudar um elemento pode exigir a mudança de outro.
A "programação OOP" é uma tubulação com dependência reduzida entre os elementos. Ou seja, um elemento pode ser substituído por outro e é menos provável que o duto deixe de funcionar. Ser capaz de decompor qualquer produção em peças independentes, padrões de entrada, etc. - é a fabricação orientada a objetos (não a programação).
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, é muito estreito falar de programação. O OOP foi aplicado com sucesso ANTES de aparecer na programação.
Estou farto do Casanovas. Você mesmo inventou um conto de fadas e acreditou nele ) como uma criança que acredita no Pai Natal, pelo amor de Deus )
Eu te invejo, Lech!
Com toda a seriedade. Deixe-me o direito de uma pequena hipérbole artística.
O número de movimentos corporais no procedimento acima...
О ! Bem dito.
Apoio total.
A quantidade de esforço corporal no código de procedimento acima precisará ser maior se for necessário fazer mudanças.
Em princípio, a quantidade de esforço corporal no OOP não pode ser menor, já que 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 fazer outra cobertura, 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 é?