hola buen día, mi nombre es jorge y quisiera resolver algunas dudas que tengo al momento de crear clases en php,
cuál es la mejor forma de crear una clase, a esto me refiero como identifico los atributos? se usa como atributo cada campo de la BD o solo se escoge el atributo que yo use en dicha clase creada, pongo como ejemplo la clase sucursales, como sería la mejor forma de crearla
agradezco su ayuda muchas gracias y espero aportar con ustedes saludos
Entender la POO
Comenzado por
jorge.developer
, mar 17 2014 09:03
5 respuestas en este tema
#3
jorge.developer
-
- Miembros
-
- 2 mensajes
Newbie
Escrito 17 marzo 2014 - 01:02
gracias lo voy a leer....
#4
jonbra
-
- Miembros
-
- 57 mensajes
Advanced Member
Escrito 19 marzo 2014 - 02:15
La POO es como tú quieres que sea.
Puedes asignar los atributos según campos en la BD y/o puedes crear nuevos atributos según necesites. Esto significa que si tienes una clase Libros, que sirve para hacer el CRUD de libros, perfectamente puedes tener un atributo que se llame total_books, que no tiene por qué estar en la BD.
La POO, por lo que he aprendido leyendo, es muy subjetiva. Tanto, que todo depende de qué quieres lograr, qué necesitas lograr, qué esperas lograr y qué tan bien sabes organizar el código.
Esto último está ligado a tus propios criterios de diseño.
PHP en este sentido, tiene las alas muy cortadas (carece de herencia múltiple).
Así que toca andar por otras sendas para hacer algo que no debería ser tan complicado (si tuviera herencia múltiple).
Por lo demás, para programar en POO necesitas visión de conjunto, reconocer las entidades y sus partes, partes comunes entre entidades y establecer un sistema de relaciones entre entidades.
Espero que te haya servido de algo.
Un saludo!
Puedes asignar los atributos según campos en la BD y/o puedes crear nuevos atributos según necesites. Esto significa que si tienes una clase Libros, que sirve para hacer el CRUD de libros, perfectamente puedes tener un atributo que se llame total_books, que no tiene por qué estar en la BD.
La POO, por lo que he aprendido leyendo, es muy subjetiva. Tanto, que todo depende de qué quieres lograr, qué necesitas lograr, qué esperas lograr y qué tan bien sabes organizar el código.
Esto último está ligado a tus propios criterios de diseño.
PHP en este sentido, tiene las alas muy cortadas (carece de herencia múltiple).
Así que toca andar por otras sendas para hacer algo que no debería ser tan complicado (si tuviera herencia múltiple).
Por lo demás, para programar en POO necesitas visión de conjunto, reconocer las entidades y sus partes, partes comunes entre entidades y establecer un sistema de relaciones entre entidades.
Espero que te haya servido de algo.
Un saludo!
#5
Delphius
-
- Administrador
-
- 6.295 mensajes
Advanced Member
- LocationArgentina
Escrito 19 marzo 2014 - 04:53
Hola, en mis años de estudiar POO, casi a un nivel purista, y ser un fiel defensor del paradigma me permito dar unos cuantos consejos... consejos que para alguien que haya leído a Larmman le resultará un tanto familiar el estilo:
No se entiende POO cuando...
1) Uno se apega a un lenguaje en particular
2) Se piensa en clases, atributos y/o métodos de forma descolgada y separadas o de forma azarosa se salta de un concepto a otro sin miramientos ni objetividad.
3) Se intenta hacer una directa correspondencia entre las entidades o tablas de una base de datos y las clases conceptuales.
4) Se intenta forzar que las clases que uno piensa previamente se ajusten a la realidad observada. O para ser más técnicos: cuando se intenta hacer que nuestras propuestas e ideas se ajusten a un análisis posterior; o visto de otra manera (y quizá más peor que la otra): pretender que el análisis se ajuste a lo que tenemos.
Esos 4 puntos son los más habituales que he visto y reconocido, tanto en mi hace unos años, como en otros que recién se están metiendo en los conceptos y cimientos fundamentales del paradigma.
El Punto1 es el más grave, y en donde no he visto, al menos en un ámbito académico, que se haga un mejor esfuerzo en recalcar ese desapego tan necesario. A tal punto se ha llegado en que se han popularizado el rídico término de PHP POO que suelo ver en el foro.
El paradigma Orientado a Objeto es único, universal. No hay varios... es el mismo. Es un concepto, un modelo, un PARADIGMA. Luego es que los lenguajes ofrecerán (o no) soporte a esto. Cada lenguaje a su modo ve la forma en como bajarlo a tierra.
Para pensar en OO, primero olvídense de la P. SI, he dicho que se olviden de la P. Un cambio que parece insinificante, una letra; pero que lo dice todo. Para programar bajo el pensamiento OO primero hay que estudiarlo. Y BIEN. Luego es que viene la parte práctica, la POO, ya si en el lenguaje que se haya elegido.
Es preferible decir POO en Delphi, por ejemplo, y no POO Delphi. Semánticamente de la primera forma estamos recalcando en como justamente llevar a cabo un A+D OO en el lenguaje Delphi. De la 2da forma estamos afirmando, y apegando un paradigma a un lenguaje en particular.
El pto 4 también es muy grave, pero con los años y la práctica, se soluciona. Y más temprano que tarde, la propia realidad nos pone en camino de como son el órden de las cosas.
Recomiendo dos lecturas:
1) Introducción a la Programación Orientada a Objetos, de Timothy Budd. Es un excelente libro que ilustra muy bien el paradigma.
2) Cuando ya se tenga asimilado el OO, se puede pasar a el libro de los tres gurús sobre UML.
3) Una vez fortalecida las anteriores lecturas, en forma paralela recomiendo que se lea UML y Patrones: Introducción al Análisis y Diseño Orientado a Objetos y una Introducción al Proceso Unificado de Craig Larmman y UML Gota a Gota de Martin Fowler y Kendall Scott. Ninguno tiene desperdicio.
Larmman aporta una rica visión, bastante práctica (para los entendidos) y muy cercana al real-life de lo que es el aplicar el A+D en el esquema OO. He notado que lo que más cuesta sobre OO es bajar las ideas en el A+D y no tan en si en el paradigma. Muchos estudiantes terminan aprendiendo los conceptos OO de memoria, pero no logran desarrollar y potenciar las habilidades para el A+D. Un gran defecto en el sistema de enseñanza. Lamentablemente.
Larmman busca llenar ese vacío y bien aprovecha UML, y asume que previamente ya se tiene entendido lo que es OO por lo que va a los bifes.
Por su parte, Fowler en UML Gota a Gota es quizá menos técnico pero más simplista y quizá más introductoria para los muy iniciados pero no ataca bien el A+D y no profundiza demasiado.
Ahora, como mensaje final dos cosas:
1) En el mundo del AOO y DOO (Análisis y Diseño Orientado a Objetos respectivamente), no existe una única respuesta verdadera. Hay tantos diseños correctos (y no necesariamente malos o erróneos) como personas en este mundo. Por lo que no tiene sentido que se le busque un santo grial, que cure sus diseños. Mi consejo basado en la experiencia: sus diseños estarán bien en cuanto dejen de sentirse intranquilos y de preguntarse demasiado si algo está bien (o mal).
El debate es bueno, pero intentar llegar a que alguien les diga la muy posta... es un juego que no les aportará sueños felices.
2)NUNCA DEJEN DE ESTUDIAR OO, Y A+D. Llevo ya casi 9 años y debo decir que cada día noto que aprendo algo nuevo. Se deben quitar de la cabeza que van a dominar OO en días, semanas, e incluso meses. No, muchachos... OO nunca se termina de aprender... sobre todo más que en nada en la forma en como uno madura en la forma de hacer A+D, y en el uso de técnicas (sobre todo en lo referente a Patrones) que permitan hacer de la OO algo intuitivo.
Asi que mi mensaje final: PACIENCIA Y MUCHA PRÁCTICA.
Saludos,
No se entiende POO cuando...
1) Uno se apega a un lenguaje en particular
2) Se piensa en clases, atributos y/o métodos de forma descolgada y separadas o de forma azarosa se salta de un concepto a otro sin miramientos ni objetividad.
3) Se intenta hacer una directa correspondencia entre las entidades o tablas de una base de datos y las clases conceptuales.
4) Se intenta forzar que las clases que uno piensa previamente se ajusten a la realidad observada. O para ser más técnicos: cuando se intenta hacer que nuestras propuestas e ideas se ajusten a un análisis posterior; o visto de otra manera (y quizá más peor que la otra): pretender que el análisis se ajuste a lo que tenemos.
Esos 4 puntos son los más habituales que he visto y reconocido, tanto en mi hace unos años, como en otros que recién se están metiendo en los conceptos y cimientos fundamentales del paradigma.
El Punto1 es el más grave, y en donde no he visto, al menos en un ámbito académico, que se haga un mejor esfuerzo en recalcar ese desapego tan necesario. A tal punto se ha llegado en que se han popularizado el rídico término de PHP POO que suelo ver en el foro.
El paradigma Orientado a Objeto es único, universal. No hay varios... es el mismo. Es un concepto, un modelo, un PARADIGMA. Luego es que los lenguajes ofrecerán (o no) soporte a esto. Cada lenguaje a su modo ve la forma en como bajarlo a tierra.
Para pensar en OO, primero olvídense de la P. SI, he dicho que se olviden de la P. Un cambio que parece insinificante, una letra; pero que lo dice todo. Para programar bajo el pensamiento OO primero hay que estudiarlo. Y BIEN. Luego es que viene la parte práctica, la POO, ya si en el lenguaje que se haya elegido.
Es preferible decir POO en Delphi, por ejemplo, y no POO Delphi. Semánticamente de la primera forma estamos recalcando en como justamente llevar a cabo un A+D OO en el lenguaje Delphi. De la 2da forma estamos afirmando, y apegando un paradigma a un lenguaje en particular.
El pto 4 también es muy grave, pero con los años y la práctica, se soluciona. Y más temprano que tarde, la propia realidad nos pone en camino de como son el órden de las cosas.
Recomiendo dos lecturas:
1) Introducción a la Programación Orientada a Objetos, de Timothy Budd. Es un excelente libro que ilustra muy bien el paradigma.
2) Cuando ya se tenga asimilado el OO, se puede pasar a el libro de los tres gurús sobre UML.
3) Una vez fortalecida las anteriores lecturas, en forma paralela recomiendo que se lea UML y Patrones: Introducción al Análisis y Diseño Orientado a Objetos y una Introducción al Proceso Unificado de Craig Larmman y UML Gota a Gota de Martin Fowler y Kendall Scott. Ninguno tiene desperdicio.
Larmman aporta una rica visión, bastante práctica (para los entendidos) y muy cercana al real-life de lo que es el aplicar el A+D en el esquema OO. He notado que lo que más cuesta sobre OO es bajar las ideas en el A+D y no tan en si en el paradigma. Muchos estudiantes terminan aprendiendo los conceptos OO de memoria, pero no logran desarrollar y potenciar las habilidades para el A+D. Un gran defecto en el sistema de enseñanza. Lamentablemente.
Larmman busca llenar ese vacío y bien aprovecha UML, y asume que previamente ya se tiene entendido lo que es OO por lo que va a los bifes.
Por su parte, Fowler en UML Gota a Gota es quizá menos técnico pero más simplista y quizá más introductoria para los muy iniciados pero no ataca bien el A+D y no profundiza demasiado.
Ahora, como mensaje final dos cosas:
1) En el mundo del AOO y DOO (Análisis y Diseño Orientado a Objetos respectivamente), no existe una única respuesta verdadera. Hay tantos diseños correctos (y no necesariamente malos o erróneos) como personas en este mundo. Por lo que no tiene sentido que se le busque un santo grial, que cure sus diseños. Mi consejo basado en la experiencia: sus diseños estarán bien en cuanto dejen de sentirse intranquilos y de preguntarse demasiado si algo está bien (o mal).
El debate es bueno, pero intentar llegar a que alguien les diga la muy posta... es un juego que no les aportará sueños felices.
2)NUNCA DEJEN DE ESTUDIAR OO, Y A+D. Llevo ya casi 9 años y debo decir que cada día noto que aprendo algo nuevo. Se deben quitar de la cabeza que van a dominar OO en días, semanas, e incluso meses. No, muchachos... OO nunca se termina de aprender... sobre todo más que en nada en la forma en como uno madura en la forma de hacer A+D, y en el uso de técnicas (sobre todo en lo referente a Patrones) que permitan hacer de la OO algo intuitivo.
Asi que mi mensaje final: PACIENCIA Y MUCHA PRÁCTICA.
Saludos,
#6
genriquez
-
- Miembro Platino
-
- 539 mensajes
Advanced Member
- LocationCali, Colombia
Escrito 20 marzo 2014 - 06:55
"El paradigma Orientado a Objeto es único, universal. No hay varios... es el mismo. Es un concepto, un modelo, un PARADIGMA. Luego es que los lenguajes ofrecerán (o no) soporte a esto. Cada lenguaje a su modo ve la forma en como bajarlo a tierra"
Muy claro Delphius, felicitaciones.
Muy claro Delphius, felicitaciones.
