Una pregunta para los expertos en POO. - página 3
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Criatura.
Flora/Fauna
Subespecie
Especies
Familia
etc.
¿Es eso lo que quieres?
Pues es una simple herencia de la entidad base "Entidad".
Pero se puede ir más allá: hay unicelulares/multicelulares, y eso es todo para los seres vivos. Pero también los hay no vivos. Todo depende de las tareas, para lo cual es necesario encontrar propiedades de un objeto base, y heredar de ellas.
Si estás realmente loco, puedes llegar a los átomos y empezar a dividirlos en partes en busca de un objeto padre fundamental (cuidado: una reacción de fisión puede convertirse en una reacción en cadena, y destruirás medio mundo :))
Sí. A primera vista, el concepto de POO es ideal para construir una jerarquía. Pero, ¿cómo se trabaja con una jerarquía construida mediante POO? Es un mar de sintaxis y complejidad de transiciones entre enlaces por los derechos de acceso a las clases y sus contenidos. Aquí es donde comienza la sobrecarga, como consecuencia de la división en clases. La POO, por un lado, permite construir una jerarquía, pero por otro lado hace que sea extremadamente difícil trabajar con ella.
Pues no. La POO ofrece un acceso muy fácil a cualquier miembro de la jerarquía en cualquier lugar.
Empieza por encontrar tu objeto base con las propiedades mínimas requeridas.
El resto de los objetos heredan de él. Para evitar reinventar la rueda, su objeto base debería heredar la clase CObject de la biblioteca estándar. Esto le permite crear su propia jerarquía de objetos sin necesidad de reinventar las listas
CObject --> CBaseObject --> su jerarquía.
En CBaseObject debe haber un método virtual que devuelva este objeto. Entonces cada uno de sus descendientes tendrá este método en consecuencia, y devolverá exactamente el objeto descendiente. La clase base de CObject ya tiene un método -Type(). Si tienes el mismo método virtual de CBaseObject, y te devuelve el tipo de objeto, sabrás a qué objeto has accedido.
Es como un fundamento básico para todos tus objetos. Y todos ellos deben ser almacenados en sus propias listas - cada lista sólo contendrá objetos de un tipo - peces, animales, humanos, dioses, etc.
Es decir, tendrá que tener una lista para cada subtipo. Y debe haber una lista, que contendrá las siguientes listas en la jerarquía. Cada una de estas listas debe tener también listas -de nuevo- que son las siguientes en la jerarquía. Y así sucesivamente.
Es decir, se necesita también un objeto de lista base, en el que se colocarán las listas necesarias. Y esta lista base debe tener un método Type(), y debe haber un método que permita devolver cualquier objeto almacenado en ella por su índice. Entonces, si se hace esto, automáticamente se tendrá un método en cualquiera de las listas que devuelva el objeto requerido.
En general, hay que pensar primero en el objeto fundación y luego en el objeto lista. Tampoco hay que crear listas de objetos, ya existen.
Y luego es una cuestión de técnica. Y sólo necesita saber el tipo de objeto que busca. Habrá muchos tipos en su jerarquía, y cada uno de ellos es conocido por usted y puede solicitarlo y recibirlo.
Como me pareció, no tiene nada que ver con la OOP en este caso.
En el caso de Peter, todos los objetos del array se buscan por alguna clave. Y no hay diferencia si se usan clases, si se usan arrays, si se usan un montón de objetos declarados en absoluto.
La POO permite tener una lista de objetos, cada uno de los cuales, digamos, tiene el método GetColor() - y el usuario recorre todos los objetos en busca del color adecuado. Pero, si sin la POO - tenemos un array de estructuras idénticas, que el usuario necesita conocer, para obtener el color de donde sea necesario, con la POO - el usuario no necesita saber exactamente cómo y dónde se almacena el color - el método GetColor() del objeto sabe, dónde obtener el color.
Por lo tanto, para OOP - el usuario no necesita saber cómo y dónde se almacena el color del objeto. Así, si de repente necesitamos añadir un "objeto para ciegos", en el que el color esté codificado por puntos en Braille, podemos añadir fácilmente este objeto a nuestra lista y cambiar sólo su método GetColor(), que recibiría el código de color de los puntos en Braille y lo devolvería en forma regular. Para el usuario de nuestra lista, nada cambiará.
Si sólo tenemos una matriz, no podemos poner "puntos braille". No tenemos ese campo en él.
El beneficio de la POO se ve muy bien cuando heredamos de CObject, luego creamos una matriz de objetos CArrayObj, y luego, escribiendo sólo la función de comparación - inmediatamente obtenemos la capacidad de ordenar rápidamente y la búsqueda binaria.
A grandes rasgos, para mi ejemplo anterior, con el color -para la POO- escribimos una función de comparación, obteniendo el color a través de GetColor(), y podemos ordenar nuestros objetos por color, incluso sin saber que tenemos la mitad de los objetos con color real y la mitad con "puntos braille".Y si queremos añadir un objeto con una nueva codificación de colores - de nuevo sólo tenemos que escribir la función GetColor(), que llevaría su representación de colores al estándar - y entonceslos algoritmos de ordenación y búsqueda ya escritos aceptarán este nuevo objeto sin problemas.
Es decir, de hecho, la programación orientada a objetos (OOP) nos permitió tener un algoritmo de ordenación y búsqueda de objetos aún no escritos, antes incluso de haber decidido cómo se representarán exactamente con un color y cómo se almacenarán.
Los beneficios de la POO son realmente claros, cuando heredamos de CObject, luego creamos un array de objetos CArrayObj, y luego, escribiendo sólo la función de comparación, obtenemos una rápida ordenación y búsqueda binaria.
Es un mar de sintaxis y dificultades con las transiciones entre enlaces debido a los derechos de acceso a las clases y sus contenidos. Aquí es donde comienza la sobrecarga, como consecuencia de la división en clases. La POO, por un lado, permite construir una jerarquía, pero por otro lado hace que sea extremadamente difícil trabajar con ella.
los modificadores de derechos de acceso permiten detectar errores en tiempo de compilación
En general, todo esto no complica el trabajo con las clases, no lo use, escribir todo en público: y entonces será más fácil trabajar con ellos.
SZZY: Un montón de frases bonitas sobre POO, encapsulación y herencia... Todo esto es bueno, pero la ventaja más importante de la POO sobre otros estilos de programación es el almacenamiento de todos los datos (campos de la clase) y las funciones de trabajo con estos datos (métodos de la clase) en un solo lugar (clase) - en libro es la encapsulación. Además, el uso de la programación orientada a objetos depende de la tarea, si la tarea permite escalar las clases, entonces se necesitará una jerarquía y habrá clases base y sus descendientes.
Debo admitir que en el concepto de OOP, "Object" se presenta en un contexto más amplio que en mi "Kernel". Pero, esto no es sorprendente, ya que hasta ahora sólo he tratado con gráficos, y la POO se utiliza para una amplia gama de tareas. Mi "menú" de objetos es bastante escaso y aparte de "etiqueta", "elemento", "ventana" probablemente no hay mucho más... Sin embargo, para las interfaces gráficas no necesito nada más.
Sin embargo, ahora se plantea la cuestión de ampliar el concepto de "Objeto" y construir una jerarquía. Un simple núcleo bidimensional no puede aceptar toda la variedad de objetos de la base de conocimientos y, por lo tanto, o bien hay que crear un núcleo diferente para los distintos objetos o seguir el concepto de POO.
En esencia, se trata de una cuestión puramente técnica. Cuál es más eficiente, cuál es más rápido, cuál es más legible, etc.
De hecho, puedes simplemente mantener todos los objetos de un array como una lista de propiedades, entre las que habrá punteros a otros arrays, con otros objetos y así sucesivamente. Opuede utilizar explícitamentela POO. La orientación a objetos está invariablemente presente en ambos enfoques, sólo los métodos de implementación son diferentes. La misma memoria, los mismos punteros, los mismos objetos, la misma clasificación. Sólo la forma del código es diferente...
Quería hablarle a Peter de esto cuando entienda el concepto de almacenamiento de datos que se le ha propuesto.
Trataré de entender este concepto de almacenamiento y manejo de datos.
De acuerdo. Podemos charlar en persona sobre el tema. O por Skype, como prefieras. Es que lo específico no está en el tema de este hilo, aquí, según entiendo, son sólo preguntas generales.