Uma pergunta para os especialistas do OOP. - página 15

 
Alexey Navoykov:
Portanto, não vejo a utilidade de contrastar seu "kung fu" especificamente com o OOP.

ele está falando sério!

Tag Konow:
Estou prestes a patentear meu conceito. Há investidores. Portanto, é sério.

ontem à noite eu li o fio do sonambulismo.... por alguma razão eu imaginei uma longa lista de desenvolvedores do Windows - como nos créditos da Guerra das Estrelas!

e no final da lista - em letras grandes ReTeg Konow !


@Peter Konow, você pode fazer um sprite como este?)
 
Alexey Navoykov:
Você se lembra de tudo no projeto em que está trabalhando no momento. E os códigos do passado? Você se lembra tão bem do que escreveu há um ano? Onde as coisas mudaram, etc. Agora a tarefa é ajustar ou corrigir seu código antigo.

E nada disso tem nada a ver com o OOP. Se seu código é construído sobre o acesso público a variáveis globais, não é aceitável em nenhum paradigma, nem em procedimento, nem em OOP, muito menos em funcional. Portanto, não vejo nenhum sentido em contrastar seu "kung fu" com o OOP.

Tudo repousa sobre a memória fenomenal de Peter.

E eu concordo, se você se lembrar de todas as variáveis que são usadas em todo o seu projeto, quando e onde elas são modificadas, facilmente encontrará lugares de modificação incorreta - então este mesmo OOP torna-se sem sentido de fato. Peter, de fato, trabalha no "nível assembler". Quaisquer que sejam os padrões de OOP-hacks e de projeto que você criar, no final qualquer acesso aos dados são endereços de memória comuns, e dentro do espaço de endereços alocado ao processo, todos os endereços de memória são totalmente acessíveis. O próprio processador não sabe nada sobre encapsulamento.

Ali, e é assim que Peter opera. Houve um tempo em que eu mesmo me dedicava à montagem.

A única questão é como ele consegue competir com o processador em termos de capacidade de memória.

 
Georgiy Merts:

Tudo isso se deve à memória fenomenal de Peter

...

A única questão é como ele consegue competir com o processador em termos de capacidade de memória.

Então, qual é o fenômeno quando estamos falando de um e o mesmo projeto em que ele está trabalhando o tempo todo. Naturalmente, qualquer programador terá tudo isso em sua cabeça o tempo todo.
Se ele pudesse se lembrar claramente do código após algum tempo, seria uma história diferente.
 
Alexey Navoykov:
Então, qual é o fenômeno se estamos falando do mesmo projeto em que ele está trabalhando o tempo todo. Naturalmente, qualquer programador terá tudo isso em sua cabeça o tempo todo.
Se ele pudesse se lembrar claramente do código depois de um tempo, então outra conversa.

Bem, então, eu não sou qualquer um. Eu também trabalho principalmente no mesmo projeto, porém, só me lembro da essência básica. Tais detalhes como o que e de que procedimento é modificado - vejo apenas no momento do desenvolvimento direto. E então, se eu volto a este site, passo muito tempo tentando entender porque isto é assim e não de outra forma. Como resultado, sou um defensor do corte de todos os direitos, de modo que, idealmente, em qualquer lugar do programa, você tenha acesso apenas ao que deve fazer naquele lugar.

 
Alexey Navoykov:
Você se lembra de tudo no projeto em que está trabalhando no momento. E os códigos do passado? Você se lembra tão bem do que escreveu há um ano? Onde as coisas mudaram, etc. Agora a tarefa é ajustar ou corrigir seu código antigo.

E nada disso tem nada a ver com o OOP. Se seu código é construído sobre o acesso público às variáveis globais, isto não é aceitável em nenhum paradigma, nem em procedimento, nem em OOP, muito menos em funcional. Portanto, não vejo nenhum sentido em contrastar seu "kung fu" com o OOP.
Sim, eu me lembro e entendo o código antigo muito rapidamente. O projeto é tão grande que algumas partes não foram trocadas por meses ou mesmo anos e quando chega a hora de melhorar algo (por exemplo, uma lista antiga) eu passo por todos os detalhes em pouco tempo, refrescando minha memória de como ele funciona, sem comentários, que são quase inexistentes no código fonte. Eu me lembro de olhar para o código nu. E por alguma razão, parece-me que todos podem fazer isso.
 

Alexey Navoykov:

...

E nada disso tem nada a ver com o OOP. Se seu código é construído sobre o acesso público a variáveis globais, não é aceitável em nenhum paradigma, nem em procedimento, nem em OOP, muito menos em funcional. Portanto, não vejo nenhum sentido em contrastar seu "kung fu" com o OOP.

Não, o kung fu aqui é exatamente OOP. Muitos movimentos e técnicas, entre os quais em uma luta 10% dos úteis. Mas que belos estilos! E dragão, e macaco, e flamingo e sapo... Eu tenho um sambo específico. Você corta e obtém o resultado.

 
Реter Konow:

Não, é o OOP que é kung fu aqui. Muitos movimentos e truques, entre os quais 10% virão a calhar numa luta. Mas que belos estilos! Dragão, macaco, flamingo e sapo... Eu tenho um sambo específico. Você corta e obtém o resultado.

Não é.

Já o disse cem vezes antes sobre a utilidade do encapsulamento e as restrições de direitos.

A utilidade da herança e do polimorfismo pode ser vista claramente quando se lida com listas de itens onde existe uma interface virtual comum, mas a implementação é significativamente diferente.

Aqui está a situação mais simples que encontrei esta semana: há uma lista de estruturas, uma das quais tem um valor duplo. A idéia surgiu para aproximar estes valores usando o OOP.

Sem o OOP, ou eu preciso escrever inteiramente os procedimentos que irão criar os SLAEs correspondentes e resolvê-los. Ou, se eu já tenho tal programa para trabalhar com uma matriz de valores - escrever procedimentos que criariam tal matriz, e passá-la para a função de biblioteca.

Com OOP - Eu herdo da classe CLSMCore, e sobrecarrego funções virtuais que retornam valores de pontos de retorno. Imediatamente eu posso obter os coeficientes do polinômio de aproximação.

Ou seja, em condições iguais (quando temos uma função ou classe de biblioteca), eu perderia sem o OOP, introduzindo uma matriz intermediária extra. Para não mencionar a necessidade de descobrir exatamente como preenchê-lo. (Funções de recuperação de valores - com ou sem OOP - precisam ser escritas). A principal vantagem, em minha opinião, é exatamente a simplicidade do apoio e da modificação. Com o OOP, há menos a entender. E no início eu gastei absolutamente tanto esforço para escrever a classe CLSMCore quanto teria gasto com a função de aproximação da biblioteca sem o OOP.

 
Georgiy Merts:

Não é.

Já o disse cem vezes antes sobre a utilidade do encapsulamento e as restrições de direitos.

A utilidade da herança e do polimorfismo é claramente observada quando se trabalha com listas de itens que compartilham uma interface virtual comum, mas a implementação é significativamente diferente.

Aqui está a situação mais simples que encontrei esta semana: há uma lista de estruturas, uma das quais tem um valor duplo. A idéia surgiu para aproximar estes valores usando o OOP.

Sem o OOP, ou eu preciso escrever inteiramente os procedimentos que criarão os SLAEs correspondentes e resolvê-los. Ou, se eu já tenho tal programa para trabalhar com uma matriz de valores - escrever procedimentos que criariam tal matriz, e passá-la para a função de biblioteca.

Com OOP - Eu herdo da classe CLSMCore, e sobrecarrego funções virtuais que retornam valores de pontos de retorno. Imediatamente eu posso obter os coeficientes do polinômio de aproximação.

Ou seja, em condições iguais (quando temos uma função ou classe de biblioteca), eu perderia sem o OOP, introduzindo uma matriz intermediária extra. Sem mencionar a necessidade de descobrir exatamente como povoá-lo. (Funções de recuperação de valores - com ou sem OOP - precisam ser escritas). A principal vantagem, em minha opinião, é exatamente a simplicidade do apoio e da modificação. Com o OOP, há menos a entender. E no início eu gastei tanto esforço para escrever a classe CLSMCore quanto teria gasto na função de aproximação da biblioteca sem o OOP.

Por exemplo, nunca entendi que função é necessária sobrecarga. É um absurdo, não é? Fazemos uma função sem parâmetros, no interior escrevemos todos os cálculos das funções sobrecarregadas, fazemos variáveis globais e temos acesso aos resultados de qualquer outra função. Bem, isso não é bom?

Mas não! Dividiremos todos os cálculos em funções com o mesmo nome, mas com parâmetros diferentes. E faremos um amontoado de parâmetros de entrada para cada função. Não. Isso não é suficiente. Vamos tornar os nomes dos parâmetros ilegíveis. E faremos todos os tipos de matrizes a serem passadas em mistura com elas. E faremos uma dúzia de tais funções para que tenhamos que refletir sobre cada uma delas. E garantiremos que o acesso a eles será criptografado. Para que a sintaxe seja mais sofisticada. Isso é profissionalismo!

Desculpe, George. Já tive o suficiente.


ZS. Apenas uma matriz global para os resultados de 10 funções sobrecarregadas e uma função sem parâmetros que faz seu trabalho. Como é pior do que isso? 10 vezes menos sintaxe.

 
Реter Konow:

Eu, por exemplo, nunca entendi porque as funções precisam ser sobrecarregadas. É ridículo, não é? Você faz uma função sem parâmetros, escreve todos os cálculos de funções sobrecarregadas dentro dela, torna as variáveis globais e tem acesso aos resultados de qualquer outra função. Bem, isso não é bom?

Mas não! Dividiremos todos os cálculos em funções com o mesmo nome, mas com parâmetros diferentes. E faremos um amontoado de parâmetros de entrada para cada função. Não. Isso não é suficiente. Vamos tornar os nomes dos parâmetros ilegíveis. E faremos todos os tipos de matrizes a serem passadas em mistura com elas. E faremos uma dúzia de tais funções para que tenhamos que refletir sobre cada uma delas. E garantiremos que o acesso a eles será criptografado. Para que a sintaxe seja mais sofisticada. Isso é profissionalismo!

Desculpe, George. Sinto muito, George.


ZS. Apenas uma matriz global para os resultados de 10 funções sobrecarregadas e uma função sem parâmetros que faz seu trabalho. Como é pior do que isso? 10 vezes menos sintaxe.

Isso mesmo, me fale mais sobre esta função. Você tem um com um interruptor do tamanho de um monstro que seleciona uma de uma dúzia de funções. Em tal mudança, é muito fácil cometer um erro ao escrever acidentalmente um código pertencente a uma das filiais que não estão lá.

As coisas são muito mais simples com uma sobrecarga. Temos dez descendentes diferentes e, a qualquer momento, trabalhamos com UMA classe, e ela tem UMA função sobrecarregável. Não podemos escrevê-lo acidentalmente em outra classe, porque temos que abrir um arquivo completamente diferente para ele.

Além disso - a própria análise nesta enorme mudança é, em minha opinião, muito mais estressante do que abrir a única classe que precisamos, e depois analisar apenas uma função.

De fato, em código de montagem, todo o manuseio deste interruptor se resume, de qualquer forma, ao mesmo swich, dependendo deste ponteiro. Mas no caso do OOP, tudo isso é escondido do programador e não interfere em seu trabalho. Sem OOP - você tem que lidar com isso.

Grosso modo, quando você caminha - você acaba enviando sinais aos seus músculos em uma certa seqüência que os move. No entanto, no nível de consciência - basta lembrar qual movimento fazer. Aqui, OOP é exatamente esse tipo de "memória de que movimento fazer". Você "não entende porque precisamos lembrar do movimento quando temos um monte de músculos, e nervos ligados a eles"... bem... Eu já disse muitas vezes antes, para os titãs de memorização, é realmente suficiente lembrar quais músculos precisam ser esticados em que seqüência ir. Não vale a pena lembrar de todo o movimento. Para outros, que não conseguem se lembrar de tanto, é muito mais razoável lembrar de todo o movimento, e o que há com os músculos, em que seqüência eles são tensionados e até que ponto - é mais razoável escondê-lo da mente.

 

Реter Konow:

Eu, por exemplo, nunca entendi porque as funções precisam ser sobrecarregadas. É ridículo, não é? Você faz uma função sem parâmetros, escreve todos os cálculos de funções sobrecarregadas dentro dela, torna as variáveis globais e tem acesso aos resultados de qualquer outra função. Bem, isso não é bom?


Tremendo, você está fazendo algum tipo de construção de bicicleta sem o estudo adequado da abordagem comum. Peter, encontre um bom livro, talvez Stroustrup, em algum livro ele escreveu um editor de texto, sobre um problema real que você vai aprender algo, não me lembro do conteúdo, mas é improvável que ele lhe ensine coisas ruins.

Razão: