tutorial poo oriented instanciar example español clases clase php oop

poo - OO explicación PHP para un braindead n00b



php poo (9)

El mejor consejo fue de: xtofl.myopenid.com ^^^^

Si no comprende los propósitos de los patrones, realmente no va a utilizar los objetos al máximo. Necesita saber por qué la herencia, el polimorfismo, las interfaces, las fábricas, los decoradores, etc. realmente hacen que el diseño sea más fácil al abordar problemas particulares.

He estado escribiendo PHP durante aproximadamente seis años y he llegado al punto en el que siento que debería estar haciendo más para escribir un código mejor. Sé que el código orientado a objetos es el camino a seguir, pero no entiendo bien el concepto.

¿Alguien puede explicar en términos que cualquier idiota puede entender, OO y cómo funciona en PHP o dirigirme a un tutorial de guía de idiotas?


En lugar de aprender OO desde cero, creo que sería más fácil si asumiera un marco que facilite la programación orientada a objetos. Le "obligará" a usar los métodos de OOP correctos; podrá aprender de la forma en que se escribe el marco de cómo hacer mejor OOP.

Yo recomendaría el framework QCodo PHP5 http://www.qcodo.com . Tiene excelentes tutoriales en video sobre cómo configurarlo, así como videos de capacitación ( http://www.qcodo.com/demos/ ).

Divulgación completa: he estado desarrollando este framework durante dos años, y contribuí con código en su base de código (así que no soy completamente imparcial :-)).


Hay una advertencia en el lugar: ¡no aprenderá la programación de OO sin aprender el diseño de OO! El concepto clave es definir las funciones que operan en sus datos junto con los datos apropiados. Luego puede decirle a sus objetos qué hacer, sin tener que consultar sus contenidos.

Seguramente eche un vistazo a la filosofía " Tell, do not ask ", y el principio "Need to Know" (también conocido como "Law of Demeter") es muy importante también.


He estado en tus zapatos, pero vi la luz después de leer este libro (¡algunas veces!) Http://www.apress.com/book/view/9781590599099 Después de leer esto, realmente lo "entendí" y No he mirado hacia atrás. Lo conseguirás en Amazon.

Espero que persistan, lo entiendan y lo amen. Cuando se una, te hará sonreír.

La composición supera a la herencia.


Otro puntero para aprender OO:

La mayoría de los tutoriales de OO se enfocarán en la herencia (por ejemplo, la clase X amplía la clase Y). Creo que esta es una mala idea. La herencia es útil, pero también puede causar problemas. Más importante aún, la herencia no es el objetivo de OO. El punto es abstracción; ocultando los detalles de implementación para que pueda trabajar con una interfaz simple. Aprenda a escribir buenas abstracciones de sus datos, y estará en buena forma. No te preocupes por la herencia de inmediato.



Recomiendo leer Code Complete . Los pocos enlaces en PHP OO son geniales, pero esto se lleva bien con la idea.


Algunas de las razones clave para usar OO son estructurar el código de una manera similar a cómo a los seres humanos nos gusta percibir y relacionarnos con las cosas, y explotar los beneficios de la economía , facilidad de mantenimiento , confiabilidad y escalabilidad .

es decir: la humanidad diseñó la rueda hace miles de años. Podemos refinarlo todo el tiempo, pero ciertamente no necesitamos volver a inventarlo de nuevo ...

1) Nos gusta categorizar cosas: "este es más grande que este", "este cuesta más que ese", "este es casi el mismo que ese".

2) Nos gusta simplificar las cosas: "OK, es un tractor con turbocompresor V8 enfriado por líquido, pero sigo girando el volante y presiono los pies en los picados para conducirlo, ¿verdad?".

3) Nos gusta estandarizar las cosas: "OK, llamemos triángulos, círculos y cuadrados a todas las FORMAS, y esperamos que todos tengan un ÁREA y una CIRCUNFERENCIA".

4) Nos gusta adaptar las cosas: "hmmm, me gusta eso, pero ¿puedo tenerlo en Racing Green?".

5) Nos gusta crear planos : "Todavía no tengo el tiempo o el dinero (o la aprobación) para construir eso, pero tendrá una puerta y un techo, y algunas ventanas y paredes".

6) Nos gusta proteger cosas: "OK, te dejaré ver el precio total, ¡pero estoy ocultando el margen que agregué de ti!".

7) Nos gusta que las cosas se comuniquen entre sí: "Quiero acceder a mi saldo bancario a través de: mi móvil, mi computadora, un cajero automático, un empleado del banco, etc.".

Para aprender a explotar OO (y ver algunas de las ventajas), entonces te sugiero que te pongas a ti mismo un ejercicio como tarea, tal vez una aplicación basada en navegador que trate con SHAPES, como círculos, rectángulos y triángulos, y haga un seguimiento de su área, color, posición e índice z, etc. A continuación, agregue cuadrados como un caso especial de rectángulo, ya que es el mismo con respecto a la mayor parte de su definición, área, etc. Simplemente tiene la condición adicional de que la altura es la misma que el ancho . Para hacerlo más difícil, entonces podrías hacer que un rectángulo sea un tipo de cuadrángulo que es un tipo de polígono. etcétera etcétera.

NOTA: No comenzaría a utilizar un Framework PHP hasta que se sienta cómodo con los principios básicos de la programación OO. Son mucho más poderosos cuando puedes extender tus clases y si no puedes, es como aprender algo de memoria -> ¡mucho más difícil!


Piensa en algo. Cualquier cosa, algo en lo que quieras hacer cosas. Diga, un desayuno.

(Todo código es pseudocódigo, cualquier parecido con cualquier idioma que viva, esté muerto o sea objeto de abusos clínicos en la industria bancaria es completamente fortuito y nada tiene que ver con que su publicación sea etiquetada como PHP)

Entonces defines una plantilla de cómo representarías un desayuno. Esta es una clase:

class Breakfast { }

Los desayunos contienen atributos. En cosas normales no orientadas a objetos, puede usar una matriz para esto:

$breakfast = array( ''toast_slices'' => 2, ''eggs'' => 2, ''egg_type'' => ''fried'', ''beans'' => ''Hell yeah'', ''bacon_rashers'' => 3 );

Y tendrías varias funciones para jugar con él:

function does_user_want_beans($breakfast){ if (isset($breakfast[''beans'']) && $breakfast[''beans''] != ''Hell no''){ return true; } return false; }

Y tienes un desastre, y no solo por los frijoles. Usted tiene una estructura de datos con la que los programadores pueden atornillar a voluntad, una colección en constante expansión de funciones relacionadas con el desayuno completamente divorciadas de la definición de los datos. Entonces, en cambio, puedes hacer esto:

class Breakfast { var $toast_slices = 2; var $eggs = 2; var $egg_type = ''fried''; var $beans = ''Hell yeah''; var $bacon_rashers = 3; function wants_beans(){ if (isset($this->beans) && $this->beans != ''Hell no''){ return true; } return true; } function moar_magic_pig($amount = 1){ $this->bacon += $amount; } function cook(){ breakfast_cook($this); } }

Y luego, manipular la idea del programa de Desayuno se vuelve mucho más limpio:

$users = fetch_list_of_users(); foreach ($users as $user){ // So this creates an instance of the Breakfast template we defined above $breakfast = new Breakfast(); if ($user->likesBacon){ $breakfast->moar_magic_pig(4); } // If you find a PECL module that does this, Email me. $breakfast->cook(); }

Creo que esto se ve más limpio, y una forma mucho más clara de representar manchas de datos que queremos tratar como un objeto consistente.

Hay mejores explicaciones de lo que OO realmente es, y por qué es académicamente mejor, pero esta es mi razón práctica, y contiene tocino.