El EOP para escolares. - página 3

 
Koldun Zloy:

Pensé que esto era obvio incluso con un pequeño número de puntos. Si hay miles de ellas, y componen formas más complejas, la ventaja será aún mayor.

Has mostrado la "técnica sintáctica" de escribir datos y trabajar con ellos. Se trata de técnicas, no del concepto de OOP. En los problemas sencillos, es más conveniente trabajar con matrices que ahuecar las entidades de cada estructura y clase, no está claro por qué se atiborran en la solución.

Existe la noción de eficiencia de los mecanismos.

La POO en tareas sencillas reduce la eficiencia y la legibilidad. Se necesita un martillo para clavar clavos y no importa si tiene una pantalla con un contador de golpes y un medidor de fuerza.

 
Реter Konow:

Has mostrado la "técnica sintáctica" de escribir datos y trabajar con ellos. Se trata de técnicas, no del concepto de POO. En las tareas sencillas, es más conveniente trabajar con arrays que crear entidades de cada estructura y clase, no está claro por qué se atiborran en la solución.

Existe la noción de eficiencia de los mecanismos.

La POO en tareas sencillas reduce la eficiencia y la legibilidad. Para clavar clavos, necesitas un martillo, y no importa si tiene una pantalla con un contador de golpes y un medidor de fuerza.

En mi ejemplo, la legibilidad es mucho mejor y la eficiencia es igual de buena.

No sé qué es el "concepto OOP".

Soy programador, no filósofo.

 
Koldun Zloy:

En mi ejemplo, la legibilidad es mucho mejor y la eficacia es igual de buena.

No sé cuál es el concepto de OOP.

Soy programador, no filósofo.

Transferir las técnicas de sintaxis de la POO a problemas pequeños, crea entidades innecesarias en la solución.

Primero hay que aprender a hacer soluciones eficientes con un mínimo de sintaxis y "objetividad". Mira los algoritmos que trabajan con el color. No hay nada superfluo ahí. Mecanismos desnudos. Es decir, martillos y clavos. Y a medida que las cosas se vuelven más complejas, pasar al concepto de "Objeto", "Clase"...

Eso es lo que yo haría. Pero, no me interpondré en tu camino.

 
Реter Konow:

Transferir las técnicas de sintaxis de la POO a problemas pequeños, crea entidades innecesarias en la solución.

Primero hay que aprender a hacer soluciones eficientes con un mínimo de sintaxis y "objetividad". Mira los algoritmos que trabajan con el color. No hay nada superfluo ahí. Mecanismos desnudos. Es decir, martillos y clavos. Y a medida que las cosas se vuelven más complejas, pasar al concepto de "Objeto", "Clase"...

Eso es lo que yo haría. Pero, no me interpondré en tu camino.

En este hilo, pido ejemplos concretos, no razonamientos abstractos. ¿Qué ha hecho la estructura dePUNTO contra ti?

A mí tampoco me molesta. Este hilo también es para ti.

 
Koldun Zloy:

¿Cambia algo?

La sintaxis cambia.

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

y viceversa:

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

 
Dmitry Fedoseev:

La sintaxis cambia.

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

y viceversa:

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

Me comunico con los que saben no ser groseros.

Y te vas a la mierda.

 
Koldun Zloy:

Me comunico con gente que sabe no ser grosera.

Y tú, vete.

Te has pasado de la raya, ¿no?

Sí... a los miembros no les gusta que les mojen en su propia mierda.


TheXpert:
esencialmente no.

Y aquí está la cosa: también les gusta lamerse.

--

Ahora, imagina que te hubiera dado toda esa mierda de un conseguidor y un colocador...

--

Koldun Zloy, cambia el nombre del tema a "colegial LLC de colegial".

 
Koldun Zloy:

En este hilo, pido ejemplos concretos, no razonamientos abstractos. ¿Cuál es su problema con la estructura delPUNTO?

A mí tampoco me molesta. Este hilo también es para ti.

Bien, pasemos al código.

¿Qué tarea se le encomendó? - Para almacenar las coordenadas de los puntos. ¿Para qué? - Para un acceso rápido.

La estructura POINT y sus instancias son entidades innecesarias en la solución si la tarea es sólo acceder rápidamente a los datos. Mira que es más fácil tener acceso a través de una 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];
  }
//--------------------------

Dices que no eres filósofo, pero la "estructura" es un concepto filosófico y su presencia en la solución debe estar justificada.

 
Реter Konow:

Bien, pasemos al código.

¿Cuál era el objetivo? - Para almacenar cómodamente las coordenadas de los puntos. ¿Para qué? - Para el acceso rápido.

La estructura POINT y sus instancias son entidades innecesarias en la solución si la tarea es sólo acceder rápidamente a los datos. Mira que es más fácil tener acceso a través de una matriz:

Dices que no eres filósofo, pero la "estructura" es un concepto filosófico y su presencia en la solución debe estar justificada.

Es un inconveniente: hay que saber qué elemento tiene x y cuál tiene y. Sin embargo, cuando se utiliza la estructura, todo queda claro y se eliminan los errores y se reduce la cantidad de código.

 
Dmitry Fedoseev:


Ahora imagínate si hubiera dado esa tontería de un conseguidor y un colocador.

¿Qué es ese galimatías? Abre la definición de getter y lee:

Unmétodoespecial para recuperar datos que están directamente restringidos

Pero el mecanismo por el que se pueden recuperar los datos privados puede ser diferente. En C# es de una manera, en C++ y MQL es de otra. Pero esto no priva a los métodos de la definición "getter".
Razón de la queja: