Modelo base y modelo extendido

[miktrv]

Hola buenas,

Estoy usando el patrón MVC, y me he dado cuenta de que quiero separar los modelos en dos partes. El modelo base, con las operaciones básicas, y el modelo extendido, con las más específicas. Sería correcto extender el segundo modelo del primero? o tendría que crear una instancia?

Un saludo y gracias!

[GatorV]

Recuerda las reglas para extender:

1.- ¿Hay una relación directa entre las clases? ej: entre Padre e Hijo, o su relación es de Uso
2.- ¿Necesitas agregar funcionalidad?

Si solo quieres extender por "limpieza" o algún caso similar, no es lo correcto hablando desde el diseño, si vas a extender porque tu clase base va a tener algunos métodos comúnes y vas a hacer hijos con funciones específicas sí es correcto ver la herencia.

Saludos.

[miktrv]

Extiendo porque las clases del modelo base, sólo tiene funcionalidades básicas, en cambio las extendidas tienen funcionalidades más peculiares y menos frecuentes dentro de la aplicación.

Entonces, si es por limpieza esta mal?

No se hasta que punto la POO es lo idea para la web..

Un saludo!

[GatorV]

Pues todo depende como estructures, por eso es importante que tengas tus modelos UML bien diseñados, así te evitas todo esto, por ejemplo si tu relación de uso es así:

BaseDAO (funcionalidades básicas) <- ProductosDAO (funciones específicas)

Puedes ver que es correcto, ya que tienes una clase Base donde tienes todas las funcionalidades básicas de tu modelo, luego tienes una especialización del modelo, que son productos, que tiene ya métodos específicos.

Si lo que quieres es hacer:

BaseDAO (Funciones básicas) <- ComplexDAO (Más funciones pero específicas)

Solo para ordenar el código, no creo que sea lo mejor, le brindas más complejidad a tu diseño, ya que no hay una herencia justificada, solamente es por tener el código en otro archivo, y es más complicado luego el tema del mantenimiento.

Pues es tú opinión respecto a la POO, pero para mí es lo ideal, ya que en sistemas muy complejos (sean Web o No) brinda un muy buen nivel de separación de capas y hace el sistema bastante sencillo, claro todo esto es sí creas tus diseños de la forma correcta, ya que puedes hacer un espagueti de código si no tienes buenas bases.

Saludos.

[miktrv]

Hola buenas de nuevo,

No estoy en contra de la POO, pero a veces pienso que se intentan justificar conceptos para que la programación orientada a objetos sirva, cuando debería de ser justo lo contrario, que la programación se adapte a todo. Ne parece lógico que exista un modelo con las funciones básicas y otro con las más complejas..

Gracias!

[miktrv]

Es más, creo que en cuanto a mantenimiento es mucho mejor tener dos modelos, uno con las funciones básicas ( lo que todos los modelos tienen, como insertar, eliminar, actualizar, etc ) y el resto en el modelo extendido, que utilizará parte del base.

[GatorV]

Pues mira, de que lo puedes hacer es posible, no hay limitantes en cuanto al lenguaje, de que sea lo correcto es otra cosa, como te digo es brindarle más complejidad a tu sistema pero al final tú como arquitecto del sistema tienes que tomar esas decisiones y decir "así es lo mejor para este sistema" sí al rato encuentras que hiciste más complejas las cosas pues ni hablar, es la cruz que se carga en los sistemas.

Y no son conceptos es al contrario dejar las cosas más simples, imagina que mañana llega otro programador a darle mantenimiento a tu sistema y le dicen "agrega este cambio pero SOLO para este módulo" puede cambiar tu clase inicial pero eso afectaría todos, entonces hereda, pero ¿hereda de quién, de la clase base, o de la especializada? empiezas a meter más problemas que soluciones.

Lo que comentas me recuerda mucho a esta imagen:

[miktrv]

jaja, muy bueno, pero no lo comparto. Creo que las funciones básicas separadas de las funciones más complejas es algo bueno para no tener que cargar un fichero con operaciones que nunca usarás. Para mi un gran defecto de la POO es que tienes que trabajar con objetos enteros, y todo son objetos.. un conjunto de funciones NO son un objeto conceptualmente... no? es como trabajar con bases de datos y objetos.. si quieres trabajar únicamente con objetos, te tienes que traer casi toda la base de datos?

[GatorV]

No, puedes hacer querys y solamente traer lo que necesites de la BDD, existen ORMs como Doctrine donde puedes usar DQL para obtener solo los datos que quieres, no es necesario traer toda la base de datos, eso es un error, y sí así lo haces en tus sistemas tienes que re-plantear el diseño que tienes.

Como te digo, eres al final el arquitecto de tu sistema, puedes hacer con él como gustes, así como un arquitecto puede hacer muchas cosas en su edificio / casa, así es como es el programador, hay cosas que se pueden hacer, otras que no se pueden hacer (limitaciones del lenguaje), y también hay cosas que se deben de hacer y otras que no se deben de hacer.

Te digo todo depende de tu relación de uso con tus clases, puedes tener un buen diseño ej:

Código:

BaseDAO          <-------- ProductDAO
- insert                          - findProducto     
- update                        - getCategoria
- delete                         - getExistence
- findById                      - getPictures

Así tienes una clase ProductDAO que hereda de BaseDAO, y tiene todas las funciones básicas y también funciones específicas del producto.

Lo que quieres hacer no es lo mejor por el simple hecho de que no esta justificada la herencia, ya que según lo que dices tú quieres hacer algo así:

BaseDAO <-- ComplexDAO <-- ConcreteDAO

O sea vas a tener tres clases (heredadas) para llegar a tu clase concreta que sí hace uso de la clase.

[miktrv]

Si, el tema de doctrine ya lo sé, también lo de las consultas. Me refería a situaciones más concretas. Supongamos que tengo un objeto usuario, que tiene instaladas unas aplicaciones, este usuario tiene un método getApps. Muy bien. Ahora supongamos que el objeto App, tiene un campo activo. Que pasa si quiero que el usuario se traiga sólo las apps que están activas? si, evidentemente por SQL se puede hacer la consulta, pero puramente con POO mi método no me sirve.. lo puedo reescribir el método getApps o puedo preguntar al objeto si esta activo o no, pero que pasa si ahora quiero que me traiga una cantidad concreta, desde una posición determinada y con una relación entre tablas determinada...

Un saludo!

[GatorV]

Entonces no sabes de DQL, puedes usar DQL, o un query para hacerlo, es por eso que debes de abstraer eso, tu método getApps debe de ser un proxy a un modelo que traiga los datos desde la BDD, eso se conoce como "lazy loading", cualquier framework decente lo hace, o bien puedes tú programar eso que traiga solo las apps activas.

Nada te limita tampoco a que le pases parámetros a tu método de getApps como el offset y la cantidad de apps a cargar, para eso las funciones aceptan parámetros, para cambiar el comportamiento de la función, y no es necesario traer toda la base de datos para eso, sí lo haces así actualmente pues vas a tener un problema muy grave de rendimiento cuando tu sistema sea muy grande.

Te invito un poco a que leas bien sobre usar un ORM como Doctrine y estudies usar DQL, aunque también lo puedes hacer programandolo tú, pero es más trabajo y mejor usa SQL para ello, para eso existe, solo es cuestión de que separes bien las capas, ej:

Código PHP:

class User {
        public function getApps($bActive = false, $offset = 0)
        {
                 $appsDAO = DAO::factory('Apps');
                 return $appsDAO->getAppsByUser($this, $bActive, $offset);
        }
}
 

Posibilidades hay muchas, formas de hacerlo también hay muchas, como te digo, todo depende de como hagas esa abstracción, y las decisiones que tomes como arquitecto de software.

Saludos.

[miktrv]

Hola, como te comentaba si conozco doctrine y trabajo con CodeIgniter y ZendFramework. De todas maneras sigo opinando que la poo esta muy bien y es muy clara, pero no es lo más optimo en cuanto a rendimiento. Acaban usando 500000 archivos para hacer un echo 'Hola Mundo';

No creo que lleguemos a ninguna conclusión, evidentemente todo se puede hacer, también con programación estructurada.

Un saludo!

[GatorV]

Pues parece que no los conocieras, ya que sigues diciendo cosas que precisamente un framework te ayuda a que no lo hagas, y que triste que pienses que se necesitan 50000 archivos para un hola mundo, sí ves la traza puedes ver que dependiendo del framework son unas cuantas clases.

Todo depende del framework que uses, y de que tantas características del framework estés usando, si lo mides por tamaño de archivos, en lugar de por los beneficios que te da, pues entonces no lo juzgas bien.

Claro, también con programación estructurada se puede hacer muchas cosas, pero por algo la POO es más limpia en sus diseños, ya que con estructurada sí hay muchas cosas que no puedes hacer, por la limitación de que no existen (Herencia, Interfaces, clases Abstractas, Poliformismo, Scoping, etc).

Por todo lo que dices en este tema, se nota que no tienes una base fuerte en cuanto a diseño de software se refiere, si no que vienes de un background de programación estructurada, te recomendaría que antes de seguir programando 'pseudo' POO, mejor leyeras libros de diseño de software, para que sirve realmente la POO, Dependency Inyection, Unit Testing, etc. cuando empieces a ver todos estos conceptos, vas a poder darte cuenta de que la programación estructurada es muy limitada, y que los diseños que puedes hacer con POO están en otro nivel.

¡Saludos!

[miktrv]

No se porque das por hecho que pienso que la programación orientada a objetos no es mejor que la estructurada.. y si tengo los conceptos claros de programación orientada a objetos, a mi me parece más triste medir un framework por los beneficios que te da, porque ai muchas cosas que dan beneficios pero son una basura. Sigo aprendiendo sobre programación orientada a objetos, y me encanta y se saco partido, la uso a diario y llevo mucho tiempo en ella, pero no por eso me vuelvo un fan incondicional de esta. Se que esta a otro nivel, pero también se que tiene sus desventajas en cuanto a rendimiento en ciertos proyectos, por cierto, creo que te equivocas juzgando a alguien sin conocerlo de nada... yo también podría decir que por tus comentarios eres un fanboy de la poo y que nunca te has cuestionado ciertos aspectos negativos de esta

Un saludo y gracias por tu tiempo!

[GatorV]

Lo doy por hecho por todo lo que dices: "hay que traer toda la base", "se necesitan 50000 archivos", "no, es por limpieza" etc, todos estos comentarios me hacen ver que no tienes una base fuerte en cuanto a POO se refiere y que haces lo que tristemente muchos hacen, que es pseudo POO, es decir programas usando POO pero como si fueran clases estructuradas, te privas de todo un mundo de cosas que te puede ofrecer la POO, ya te mencione algunas, lee un poco sobre ellas, en un principio se escucha complicado, pero conforme entiendes el concepto puedes ver que hacen las cosas aún más sencillas.

El único detalle "malo" que le veo (que ni es malo) como dices es la cantidad de clases que puedes hacer para hacer algo que a lo mejor estructurado te tomaría un par de funciones, pero no es un detalle negativo, la programación en capas es la base de la POO, y es de donde llegan todos sus beneficios.

Sí la POO fuera tan mala como indicas, ninguna de las empresas actuales lo usaría y todos estaríamos ahorita programando de forma estructurada, pero tiene tantos beneficios que muchos sistemas legacy poco a poco se van transformando a lenguajes de alto nivel que solo dan soporte a POO (Java, .NET).

Saludos.

[miktrv]

Hola buenas de nuevo,

Creía que entendías que "hay que traer toda la base", "se necesitan 50000 archivos" son exageraciones, yo mismo te he puesto posibles soluciones con lo de getApps... y vuelves con lo de "Sí la POO fuera tan mala como indicas", no digo que sea mala! sigo que también tiene sus defectos,

Lo de las empresas no me parece un gran argumento. Las empresas usan lo que les dicen que usen y lo que les mandan, sólo hace falta ver que cada empresa saca un tipo de software y de una manera determinada.

Un saludo!

[GatorV]

Lo que pasa es que esos "defectos" son los que inyectamos nosotros como programadores, como tal el paradigma de diseño es bueno, el problema es cuando pasas del diseño, a ya el código, pasa lo mismo que con los patrones de diseño, como patrón es interesante y soluciona un problema en concreto, pero al quererlo generalizar y usarlo de manera general en un problema específico es donde empiezan a salir los problemas.

Todos los defectos que mencionas son problemas ya a la hora de implementación, pero el paradigma como tal es eficiente.

Saludos.

[miktrv]

Hola buenas de nuevo,

Si.. pero considero que POO no es perfecto, y tiene sus defectos.. nada más. A veces se intenta representar la realidad sólo con objetos.. es decir, todo son objetos.. conceptualmente.. no me parece que un modelo , que en definitiva es un conjunto de funciones sea un objeto.. todo pasa a ser un objeto.. cada letra un objeto? al final ai un criterio que define lo que es objeto y lo que no, y por lo tanto, lo que para uno es un objeto para otro no lo es. También creo que aparte de pensar en la parte de representar en la programación la realidad mediante objetos, ai que pensar en el rendimiento de la aplicación, y más, si es web, y esta pensada para que cargue rápidamente y consuma los mínimos recursos posibles ( que a veces parece que esto se olvida en algunos FW ), como es posible que no pueda dividir un objeto o usar parte de el sin tener que cargarlo por completo?

no sé.. quizás como tu dices son cosas de "novato", para mi son preguntas que no tienen nada que ver con la experiencia, más bien con la manera de ver las cosas.

Un saludo y gracias!

[GatorV]

Lo que pasa es que ahí estas hablando de las deficiencias que tienes en el conocimiento del lenguaje, aunque "dividas" tu objeto, al referenciarlo PHP va a compilarlo y dejarlo en memoria, este es el único paso que toma "tiempo" de CPU, luego al ejecutarlo es cuando realmente toma el tiempo, aunque este todo en memoria, así que es lo mismo, te estas fijando realmente en cosas que no tienen nada que ver.

También piensa en esto, cuantos FW haz visto que sean POO y cuantos no, y cuales son los más populares, ahí te puedes dar cuenta de cual paradigma de programación es más popular, como te digo, si fuera tan ineficiente como lo expones, no se usaría, y al contrario es mucho más popular.

También revisa cuantos lenguajes (actuales) ofrecen soporte a programación estructurada y cuales son puros POO, te estas clavando en cosas que no tendrías que tomar en cuenta, esas "desventajas" son fácilmente opacadas por todas las ventajas que te da la POO y los paradigmas de programación.

Saludos.