Estuvimos investigado por distintos sitios y así regalarte la solución a tu dilema, en caso de dudas déjanos tu inquietud y responderemos con gusto.
Solución:
La programación orientada a objetos no se trata solo de cómo se ve y funciona una sola clase. También se trata de cómo funcionan juntas las instancias de una o más clases.
Es por eso que ves tantos ejemplos basados en “Autos” y “Personas” porque en realidad hacen un muy buen trabajo al ilustrar este principio.
En mi opinión, las lecciones más importantes de la programación orientada a objetos son encapsulamiento y polimorfismo.
Encapsulamiento: Acoplamiento de datos y la lógica que actúa sobre esos datos juntos de una manera concisa y lógica
Polimorfismo: La capacidad de un objeto para parecerse y / o comportarse como otro.
Un buen ejemplo del mundo real de esto sería algo así como un iterador de directorio. ¿Dónde está este directorio? Tal vez sea una carpeta local, tal vez sea remota como un servidor FTP. ¡Quién sabe!
Aquí hay un árbol de clases básico que demuestra la encapsulación:
root = $root;
class LocalDirectoryIterator extends AbstractDirectoryIterator
public function listDirs()
// logic to get the current directory nodes and return them
class FtpDirectoryIterator extends AbstractDirectoryIterator
public function listDirs()
// logic to get the current directory nodes and return them
Cada clase / objeto es responsable de su propio método de recuperar una lista de directorios. Los datos (variables) se acoplan a la lógica (funciones de clase, es decir, métodos) que utilizan los datos.
Pero la historia no ha terminado, ¿recuerdas que dije que la programación orientada a objetos se trata de cómo las instancias de clases funcionan juntas, y no de una sola clase u objeto?
Bien, hagamos algo con estos datos: ¿imprimirlos en la pantalla? Seguro. ¿Pero cómo? HTML? ¿Texto sin formato? RSS? Abordemos eso.
iterator = $iterator;
public function render()
$dirs = $this->iterator->listDirs();
foreach ($dirs as $dir)
$this->renderDirectory($dir);
abstract protected function renderDirectory($directory);
class PlainTextDirectoryRenderer extends AbstractDirectoryRenderer
protected function renderDirectory($directory)
echo $directory, "n";
class HtmlDirectoryRenderer extends AbstractDirectoryRenderer
protected function renderDirectory($directory)
echo $directory, "
";
Bien, ahora tenemos un par de árboles de clases para recorrer y representar listas de directorios. ¿Cómo los usamos?
// Print a remote directory as HTML
$data = new HtmlDirectoryRenderer(
new FtpDirectoryIterator('ftp://example.com/path')
);
$data->render();
// Print a local directory a plain text
$data = new PlainTextDirectoryRenderer(
new LocalDirectoryIterator('/home/pbailey')
);
$data->render();
Ahora, sé lo que estás pensando, “¡Pero Peter, no necesito estos árboles de clase grande para hacer esto!” pero si crees que estás perdiendo el punto, al igual que sospecho que has estado con los ejemplos “Coche” y “Personas”. No se centre en las minucias del ejemplo; en su lugar, intente comprender lo que está sucediendo aquí.
Hemos creado dos árboles de clases donde uno (*DirectoryRenderer) usa el otro (*DirectoryIterator) de la manera esperada – esto a menudo se denomina contrato. Una instancia de *DirectoryRenderer no le importa qué tipo de instancia de *DirectoryIterator recibe, ni tampoco instancias de *DirectoryIterator se preocupan por cómo se representan.
¿Por qué? Porque los hemos diseñado de esa manera. Simplemente se conectan entre sí y funcionan. Esto es OOP en acción.
Compre un libro como “Aplicaciones diarias PHP y Mysql para principiantes”.
Es viejo, lo sé [2005] pero muestra conceptos de inicios de sesión de usuario, foros, carritos de la compra, etc. tanto en procedimientos como orientados a objetos con Mysqli.
Me ayudó a aprender PHP orientado a objetos, lo estudié mucho. Bien vale la pena el dinero.
OOP es muy parecido a agrupar partes de su programa en partes reutilizables. No es tan difícil ser honesto contigo, es solo la idea de empaquetar tus funciones en clases.
Mini ejemplo del mundo real de cosas de OOP a continuación:
BASE DE DATOS DE CLASE
SESIONES CLASE
FORMULARIOS WEB DE CLASES
CORREO ELECTRÓNICO DE LA CLASE
CUENTAS DE CLASE (Funciones de ejemplo a continuación)
FUNCIÓN SELECCIONAR CUENTA
CONTRASEÑA DE COMPROBACIÓN DE FUNCIÓN
COMPROBACIÓN DE FUNCIONES NOMBRE DE USUARIO
FUNCIÓN CREAR CUENTA
Espero que sigas así, PHP 6 se rediseñará para admitir POO más que nunca.
¡Buena suerte!
Si bien sé que esta pregunta ya ha sido respondida, siento que puedo agregar valor aquí.
No creo que debas usar PHP como lenguaje de programación para aprender OOP. Si desea aprender OOP para aplicaciones web, realmente debería estar mirando C # o Java. Una vez que haya aprendido OOP, puede aplicar este conocimiento a PHP. Un ejemplo de un libro que solía aprender OOP era Big Java by Cay S. Horstmann
¿Por qué digo esto ??? Debido a que hay literalmente millones de ejemplos en PHP de cómo hacer cosas, sin embargo, no muchos son ejemplos de cómo programar correctamente. Además de esto, PHP le permite tomar muchos atajos, lo que no sería aceptable con Java. Como tal, si programa PHP con una cabeza Java, creo que será un programador más fuerte. La programación orientada a objetos no es un lenguaje específico, es un paradigma de programación.
Si debe aprender OOP usando PHP, le recomendaría que eche un vistazo a algún código fuente real en los repositorios públicos de github. Puede buscarlos en packagist.org. Si son un repositorio público decente, contendrán un archivo readme.md que le mostrará cómo usar los paquetes del compositor. por ejemplo, https://github.com/moltin/laravel-cart es un ejemplo de un paquete de carrito de compras que podría utilizar en su aplicación. Observe que no necesita mirar el código fuente del paquete para comprender qué hacen los paquetes. El paquete se ha escrito y no le importa cómo funcionan, pero los usa, por lo que solo necesita saber cómo usarlos. Esto es exactamente de lo que se trata OOP.
No me importa cómo la clase de carrito de compras agrega un artículo al carrito, solo quiero crear un nuevo carrito y agregarle algo.
Sin embargo, lo que está haciendo es sumergirse en el código fuente como una herramienta para comprender cómo funciona la programación orientada a objetos.
Además de esto, y probablemente más importante, para el desarrollo de aplicaciones web, investigaría el patrón de diseño MVC.
El patrón de diseño MVC significa Modelo, Vista, Controlador. Cuando en el caso de una aplicación web, el modelo es responsable de modelar la base de datos, la vista es responsable de mostrar el contenido al usuario. El controlador es responsable de interactuar con el modelo y manejar la entrada del usuario.
Entonces creo que deberías intentar instalar Laravel Framework u otro “marco moderno decente” en tu máquina local. ¿Por qué digo moderno, porque los marcos modernos requieren una versión mínima de PHP de 5.3+, lo que significa que PHP en su máquina admitiría OOP real similar a la que obtendría de Java.
Hay muchos tutoriales que le mostrarán cómo crear aplicaciones web en laravel. Inmediatamente, verá que cuando crea un controlador, extiende un BaseController. Cuando creas un modelo, extiendes Eloquent. Esto significa que ya estará usando polimorfismo en su código. Verás que al usar clases, se encapsulan y verás que cada clase tiene un rol específico.
Cuando desee interactuar con la base de datos, inicialmente creará una new Model objeto dentro de los métodos del controlador. A medida que comience a aprender más, comenzará a aprender cómo inyectar dependencias en el controlador, luego aprenderá cómo volcar sus modelos y crear repositorios y programar en interfaces en su lugar.
Un libro decente sobre el aprendizaje de Laravel para principiantes sería https://leanpub.com/codebright de Dale Rees. Conocí a Dale en una reunión de Laravel hace aproximadamente 2 semanas.
Además de esto, a medida que se vuelva más competente en la creación de aplicaciones web, comenzará a aprender a aplicar los siguientes principios a su programación:
- Principio de responsabilidad única
- Principio abierto cerrado
- Principio de sustitución de Liskov
- Principio de separación de la interfaz
- Principio de inversión de dependencia