O POE para crianças em idade escolar. - página 3

 
Koldun Zloy:

Pensei que isto era óbvio mesmo com um pequeno número de pontos. Se houver milhares deles, e eles compõem formas mais complexas, a vantagem será ainda maior.

Você mostrou a "técnica sintáctica" de escrever dados e trabalhar com eles. Estas são técnicas, não o conceito de OOP. Em problemas simples, é mais conveniente trabalhar com matrizes do que com entidades ocas de cada estrutura e classe, não está claro porque elas são espremidas para a solução.

Existe uma noção como: eficiência do mecanismo.

OOP em tarefas simples reduz a eficiência e a legibilidade. Você precisa de um martelo para martelar pregos e não importa se ele tem um mostrador com um contador de punção e um medidor de força.

 
Реter Konow:

Você mostrou a "técnica sintáctica" de escrever dados e trabalhar com eles. Estas são técnicas, não o conceito de OOP. Em tarefas simples, é mais conveniente trabalhar com matrizes do que construir entidades a partir de cada estrutura e classe, não está claro porque elas estão amontoadas na solução.

Existe uma noção como: eficiência do mecanismo.

OOP em tarefas simples reduz a eficiência e a legibilidade. Para martelar pregos, você precisa de um martelo, e não importa se ele tem um mostrador com um contador de punção e um medidor de força.

No meu exemplo, a legibilidade é muito melhor e a eficiência é igualmente boa.

Eu não sei o que é o "conceito OOP".

Eu sou um programador, não um filósofo.

 
Koldun Zloy:

No meu exemplo, a legibilidade é muito melhor e a eficiência é igualmente boa.

Eu não sei qual é o conceito de OOP.

Eu sou um programador, não um filósofo.

A transferência de técnicas de sintaxe do OOP para pequenos problemas, cria entidades desnecessárias na solução.

Primeiro você tem que aprender como fazer soluções eficientes com o mínimo de sintaxe e "objetividade". Veja os algoritmos que funcionam com cores. Lá não há nada supérfluo. Mecanismos nus. Ou seja, martelos e pregos. E à medida que as coisas se tornam mais complexas, passemos ao conceito de "Objeto", "Classe"...

Isso é o que eu faria. Mas, eu não vou atrapalhar seu caminho.

 
Реter Konow:

A transferência de técnicas de sintaxe do OOP para pequenos problemas, cria entidades desnecessárias na solução.

Primeiro você tem que aprender como fazer soluções eficientes com o mínimo de sintaxe e "objetividade". Veja os algoritmos que funcionam com cores. Lá não há nada supérfluo. Mecanismos nus. Ou seja, martelos e pregos. E à medida que as coisas se tornam mais complexas, passemos ao conceito de "Objeto", "Classe"...

Isso é o que eu faria. Mas, eu não vou atrapalhar seu caminho.

Nesta linha, estou pedindo exemplos concretos, não raciocínios abstratos. O que a estrutura doPOINT fez contra você?

Você também não está me incomodando. Esta linha também é para você.

 
Koldun Zloy:

Será que isso muda alguma coisa?

A sintaxe muda.

obj.val=1; ou obj.val(1);

e vice versa:

x=obj.val; ou x=obj.val();

 
Dmitry Fedoseev:

A sintaxe muda.

obj.val=1; ou obj.val(1);

e vice versa:

x=obj.val; ou x=obj.val();

Eu me comunico com aqueles que sabem como não ser rude.

E você sai daqui para fora.

 
Koldun Zloy:

Eu me comunico com pessoas que sabem como não ser rude.

E você, saia.

Você está fora da linha, não está?

Sim... os membros realmente não gostam de ser mergulhados em suas próprias besteiras.


TheXpert:
essencialmente não.

E é o seguinte: eles também gostam de se lamber um ao outro.

--

Agora, imagine se eu tivesse dito essas coisas sobre um getter e um setter...

--

Koldun Zloy, renomeou o tópico para "schoolboy LLC de schoolboy".

 
Koldun Zloy:

Nesta linha, estou pedindo exemplos concretos, não raciocínios abstratos. Qual é o seu problema com a estrutura doPONTO?

Você também não está me incomodando. Esta linha também é para você.

Ok, vamos passar para o código.

Que tarefa foi definida? - Para armazenar as coordenadas dos pontos. Para quê? - Para acesso rápido.

A estrutura do POINT e suas instâncias são entidades desnecessárias na solução se a tarefa for apenas acessar rapidamente os dados. Veja como é muito mais fácil ter acesso através de uma matriz:

int Points[2][10]; //Объявляем в глобальной области.
//---------------------
//цикл по точкам для вычесления расстояний между ними:
//---------------------
for(int i = 0; i < 9; i++)
  {  
   int x_dist = Points[0][i + 1] - Points[0][i];
   int y_dist = Points[1][i + 1] - Points[1][i];
  }
//--------------------------

Você diz que não é um filósofo, mas "estrutura" é um conceito filosófico e sua presença na solução deve ser justificada.

 
Реter Konow:

OK, vamos passar para o código.

Qual era o objetivo? - Para armazenar convenientemente as coordenadas dos pontos. Para quê? - Para o acesso rápido.

A estrutura do POINT e suas instâncias são entidades desnecessárias na solução se a tarefa for apenas acessar rapidamente os dados. Veja como é muito mais fácil ter acesso através de uma matriz:

Você diz que não é um filósofo, mas "estrutura" é um conceito filosófico e sua presença na solução deve ser justificada.

É apenas inconveniente - você precisa saber qual elemento tem x e qual tem y. Ao utilizar a estrutura, porém, tudo é claro, e elimina erros e reduz a quantidade de código.

 
Dmitry Fedoseev:


Agora imagine se eu tivesse dado aquele disparate sobre um getter e um setter.

O que é a algaraviada? Abra a definição de getter e leia:

ummétodoespecial de recuperação de dados que é diretamente restrito

Mas o mecanismo pelo qual os dados privados podem ser recuperados pode ser diferente. Em C# é uma maneira, em C++ e MQL é outra. Mas isto não priva os métodos da definição de "getter".
Razão: