Aprendiendo a pensar en la forma orientada a objetos

Question

Soy un programador que intenta aprender a codificar en el paradigma orientado a objetos ... Principalmente trabajo con PHP y pensé en aprender el framework zend ... Entonces, sentí que necesitaba aprender a código en PHP OO ....

el problema es, después de haber hecho usando funciones desde hace mucho tiempo, yo simplemente no puedo conseguir mi cabeza para pensar en la forma OO ....

También sentí que probablemente no soy el único que enfrenta este problema desde el principio de los tiempos ...

Así que, ¿cómo aprendieron ustedes la programación orientada a objetos ... especialmente cómo tuvieron éxito? n "desaprender" al código usando funciones ... y aprender a ver tu código como objetos ...?

¿Hay buenos libros de recursos o sitios donde se pueda encontrar ayuda ...?

Gracias por compartir sus conocimientos y experiencias ...

Answer 1

1. leer el código de otras personas - la gente que sabe que son buenos desarrolladores
2. libros/artículos que enseñan "el uso idiomáticas" de la lengua
3. (Evite cualquier cosa con las palabras "en 21 días")

Answer 2

Toma tiempo.

Pasar de la programación de procedimientos a la orientación a objetos es difícil. Hoy en día, mucha gente comienza con orientación a objetos, por lo que no tienen problemas con este cambio de paradigma.

• aprender acerca de los fundamentals de programación orientada a objetos y mantener refiriéndose a ellos para empezar.
• Lea el código OO: hay muchos proyectos de código abierto que puede probar.

Answer 3

que he estado haciendo con el desarrollo de software orientado a objetos hace más de 20 años, y te puedo decir que mirar el código de otras personas es más a menudo que no va a enseñar cómo hacer la programación de procedimiento en un objeto orientado idioma.

Lo que recomendaría es utilizar las siguientes técnicas, que si se aplican liberalmente, le obligarán a utilizar técnicas OO, aunque es posible que aún no las conozca.

1. No se puede copiar y pegar el código nunca.
2. Cree clases que representen las cosas de las que habla al hablar de la funcionalidad; por ejemplo, un sistema de entrada de órdenes tendrá Órdenes, Clientes, Cuentas, Artículos de pedido, Elementos de inventario, etc.
3. Al crear estas clases, NO codifique cualquier conjunto público y obtener métodos para acceder a los miembros de datos de la clase.
4. Agregue métodos a estas clases de modelo de dominio que realizan el trabajo en el objeto en cuestión. Order.invoice(), account.close(), InventoryItem.decrement(). La falta de métodos get públicos le mostrará la ubicación correcta del código (donde están los datos, en el objeto de dominio apropiado). Recuerde, un objeto son los datos y el código que opera en él, cualquier cosa menos que ambos no es un objeto.
5. Eventualmente encontrará que tiene que agregar algunos métodos de obtención pública para algunos miembros de la clase, y eso está bien, simplemente espere hasta que se vea obligado a hacerlo. Agregar de mala gana los métodos de obtención pública.
6. En el nivel de la aplicación, casi todas las líneas de código deben estar moviendo montañas. En otras palabras, la mayoría de las líneas de código en el nivel de aplicación deberían invocar métodos de modelo de dominio.
7. Ponga toda la funcionalidad en los objetos del modelo de dominio, luego exponga esa funcionalidad en una aplicación conectándola a una interfaz de usuario. Repito, ponga la funcionalidad en el modelo de dominio, no en la aplicación.

Si sigue estas pautas, definitivamente producirá código orientado a objetos, y probablemente en un nivel mucho más alto de competencia que muchos desarrolladores experimentados.

Por último, evite la inyección, es decir, Spring, Unity, etc. Probablemente haya un puñado de casos válidos para usar inyección: la mayoría de los usos surgen de la falta de experiencia de diseño orientada a objetos. Como una guía sobre si inyectar o no, considere con qué frecuencia es probable que cambie lo que está pensando en inyectar. En muchos casos, creo que lo que se inyecta nunca cambiará; en estos casos, lo único que se inyecta es una sobrecarga pura.

¡Buena suerte!