php - tecnicas - ¿Cómo me salgo del hábito de la programación de procedimientos y de la programación orientada a objetos?

tipos de lenguaje programacion (20)

Espero obtener algunos consejos que me ayuden a romper con lo que considero después de todos estos años un mal hábito de la programación de procedimientos. Cada vez que intento hacer un proyecto en OOP, termino volviendo a los procedimientos. Supongo que no estoy completamente convencido con OOP (¡aunque creo que he oído todo lo bueno sobre esto!).

Así que supongo que algunos buenos ejemplos prácticos de tareas de programación comunes que a menudo llevo a cabo, como la autenticación / gestión de usuarios, el análisis de datos, CMS / Blogging / eComs son el tipo de cosas que hago a menudo, sin embargo, no he podido obtener mi Conozca cómo realizarlos en OOP y alejarse de los procedimientos, especialmente porque los sistemas que construyo funcionan y funcionan bien.

Una cosa que puedo ver como un inconveniente para mi desarrollo, es que reutilizo mi código a menudo, y a menudo necesita más reescrituras y mejoras, pero a veces considero esto como una evolución natural del desarrollo de mi software.

Sin embargo, quiero cambiar! a mis compañeros programadores, ayuda :) ¿Algún consejo sobre cómo puedo salir de este desagradable hábito?

Creo que la mecánica de la OOP parece completamente arbitraria y no tiene sentido hasta que lees un libro sobre patrones de diseño y entiendes el "por qué". Recomiendo Head First Design Patterns. Pensé que OOP era ridículo y completamente inútil hasta que tomé este libro y vi para lo que era realmente bueno.
OO tiene mucho más sentido cuando comprende los punteros de función y cómo se relaciona con las llamadas de función indirectas y el enlace tardío. Juegue un poco con los punteros de función en C, C ++ o D por un rato y descubra para qué sirven y cómo funcionan. La parte de polimorfismo / función virtual de OO es solo otra capa de abstracción además de esto.
El procedimiento es la herramienta adecuada para algunos trabajos. No actúes como si estuviera mal. En mi humilde opinión, los tres paradigmas principales (procedimental, OO, funcional) son valiosos incluso en un nivel específico, dentro de un solo módulo . Tiendo a preferir

El procedimiento es bueno cuando mi problema es simple (o ya lo he factorizado lo suficiente con funcional y OO que ahora tengo un subproblema que considero simple) y quiero la solución más directa sin que haya una gran cantidad de abstracción en el camino.

La orientación a objetos es buena cuando mi problema es más complejo y tiene muchos estados que tienen sentido en el contexto del dominio del problema. En estos casos, la existencia del estado no es un detalle de implementación, pero la representación exacta es una que prefiero abstraer.

Funcional es bueno cuando mi problema es complejo pero no tiene un estado que tenga sentido en el nivel del dominio del problema. Desde la perspectiva del dominio del problema, la existencia del estado es un detalle de la implementación.

¿Cuál es el punto en el uso de la programación orientada a objetos cuando no puede encontrar buenas razones o motivación para hacerlo?

Debe estar motivado por la necesidad de concebir y manipular ideas como objetos. Hay personas que sienten la necesidad de ser perceptivos de los conceptos, el flujo o las funciones en lugar de los objetos y luego están motivados hacia la programación orientada hacia los conceptos, las ideas o el flujo funcional.

Hace unos 13 años, cambié a c ++ desde c simplemente porque había ideas que necesitaba pero c no podría realizar fácilmente. En resumen, mi necesidad motivó mi programación orientada hacia los objetos.

La mentalidad orientada a objetos.

Primero, tienes bytes, caracteres, enteros y flotadores.

Entonces su programa comienza a estar abarrotado de todo tipo de variables, locales y estáticas. Luego decide agruparlos en estructuras porque calculó que todas las variables que comúnmente se pasan.

Conglomerado de datos.

Entonces, al igual que la información de la impresora, todas las variables deben estar incluidas en la estructura de la impresora:

{id, name, location, impactType(laser|inkjet|ribbon), manufacturer, networkAddr}, etc.

De modo que ahora, cuando llama a la función después de la función sobre la información de la impresora, no tiene funciones con una larga lista de argumentos o una gran colección de variables estáticas con grandes posibilidades de interferencia.

Incorporacion de informacion

Pero el conglomerado de datos no es lo suficientemente bueno. Todavía tengo que depender de un montón de funciones para procesar los datos. Por lo tanto, tuve una idea inteligente o la incorporación de punteros de función en la estructura de la impresora.

{id, name, location, impactType(laser|inkjet|ribbon), manufacturer, networkAddr, *print(struct printer), *clean(struct printer) }

Los datos se convierten en información cuando los datos contienen los procesos sobre cómo tratar / percibir los datos.

Cuantización de la información

Ahora las impresoras láser, de cinta y de inyección de tinta no tienen todas el mismo conjunto de información, pero todas tienen el conjunto más común de denominadores (LCD) en información:

Información común a cualquier impresora: ID, nombre, ubicación, etc.

Información que se encuentra solo en las impresoras de cinta: usados, ciclos, cinta (tela | celofán), bandas de colores, etc.

Información encontrada solo en inyección de tinta: cartuchos de tinta, etc.

Información encontrada solo en láseres: ...

Para mí y muchas cohortes orientadas a objetos, preferimos cuantificar toda la información común en una encapsulación de información común, en lugar de definir una estructura / encapsulación por separado para cada tipo de impresora.

Luego, preferimos usar un marco que administre todas las funciones de referencia para cada tipo de impresora porque no todas las impresoras se imprimen o se limpian de la misma manera.

Entonces, ¿su preferencia / motivación orientada a alejarse de los objetos le está diciendo que su vida de programación es más fácil si no usa objetos? Que prefieras gestionar todas esas complejidades estructurales tú mismo. No debe haber escrito suficiente software para sentirse de esa manera.

La necesidad de la pereza.

Algunas personas dicen que la necesidad es la madre de la creatividad. (así como, el amor al dinero es la raíz del mal).

Pero para mí y mis compañeros, la pereza ante la necesidad son los padres de la creatividad. (así como la falta de dinero es el otro padre del mal).

Por lo tanto, le insto a que adopte una actitud perezosa hacia la programación, de modo que el principio del camino más corto entraría en su vida y lo encontrará, pero no tendrá otra opción que graduarse para orientarse hacia la programación con objetos.

Aprende un nuevo idioma, uno que te ayude a moverte suavemente a OOP. Java es bueno, pero un poco hinchado, sin embargo. Pero su biblioteca de sistema es principalmente OO, por lo que está obligado a usar objetos. Pasar a otro idioma también le ayuda a no reutilizar su código anterior :-)

Bueno, primero que nada, los patrones de diseño son lo peor para modelar tu programación.

Es sólo un gran conjunto de cosas. No tiene nada que ver con la POO, y la mayoría de ellos, como el singleton, se utilizan constantemente por todos los motivos incorrectos (es decir, la inicialización). Algunas de estas cosas que tiene que usar, por lo que hablar de ellas no tiene sentido, otras son contraproducentes, y el resto son cosas de casos especiales. Si tratas de aprender algo de esta manera, todo empezará a parecerse a algún extraño doodad que se le ocurrió a un problema muy especial o porque necesitaba una generosidad infinita (lo que rara vez es cierto). No permita que las personas lo convenzan de usar un millón de iteradores y plantillas sin ninguna razón y compliquen las cosas diez veces.

Realmente OOP es un tema simple que se complica enormemente. Desafortunadamente en C ++ tiene muchos problemas, pero los métodos virtuales realmente simples son lo que importa. Las clases base virtuales puras utilizadas de manera muy similar a un objeto de interfaz Java son las más útiles, pero también los métodos virtuales simples aquí y allá serán útiles.

En su mayoría ha sido exagerada. Tampoco se presta bien a todos los problemas. Si haces una base de datos y cosas de gui, se adapta bien a eso. Si haces herramientas de sistema, por lo general no es tan útil.

Creo que debería convencerse a sí mismo investigando todos los inconvenientes con la programación de procedimientos, por ejemplo (algunas palabras de moda a continuación, tenga cuidado): alcance, estado ... prácticamente podrá extraer muchos términos simplemente leyendo ejemplos de patrones de diseño (lea: ejemplos comunes de uso de objetos juntos.)

Estresarse para aprender algo en lo que no cree no lo llevará a ningún lado. Comience a ser realmente crítico con su trabajo anterior y refájelo para evitar copiar el código y utilizar el alcance global, y se encontrará con ganas de más.

Creo que es útil repasar primero un código existente, decente y probado orientado a objetos (por ejemplo, el código fuente Qt) para que pueda tener una idea de "cómo se hace". Después de eso, aprender de un libro o crear su propio marco será mucho más efectivo.

En general, realmente ayuda ver las cosas en contexto antes de leerlas y practicarlas, ya que te da momentos para decirte a ti mismo: "¡Oh, es por eso que hicieron eso!" Al menos así es como funciona para mí.

Creo que es importante aprender la teoría primero. Así que leer un libro sería un buen comienzo.

Descubrí que una de las cosas que realmente me ayudó a consolidar los beneficios de la POO para mí ha sido escribir pruebas unitarias con un marco de objeto simulado (como EasyMock ). Una vez que comienza a desarrollarse de esa manera, puede ver cómo las clases lo ayudan a aislar los módulos detrás de las interfaces y también permiten realizar pruebas más fácilmente.

Una cosa que hay que tener en cuenta es que cuando las personas están aprendiendo la POO por primera vez, a menudo hay un énfasis excesivo en la herencia. La herencia tiene su lugar, pero es una herramienta que puede ser usada en exceso fácilmente. La composición o la implementación de una interfaz simple a menudo son mejores formas de hacer las cosas. No vaya tan lejos al intentar reutilizar el código por herencia, ya que creará árboles de herencia que no tienen mucho sentido desde el punto de vista del polimorfismo. El principio de sustitución es lo que hace que la implementación de herencia / interfaz sea poderosa, no el hecho de que se pueda reutilizar el código por subclasificación.

Descubrí que una forma muy intensa de aprender a entrenar la abstracción en la programación es construir una biblioteca OOP con una funcionalidad definida, y luego implementar dos proyectos con requisitos similares pero aún diferentes que se están desarrollando en esa biblioteca, al mismo tiempo.

Esto requiere mucho tiempo y debe haber aprendido primero los conceptos básicos de la POO (S.Lott tiene algunos enlaces excelentes en la otra respuesta). Refactorización constante y un montón de "Doh!" los momentos son la regla; pero encontré que esta era una excelente manera de aprender programación modular porque todo lo que hice se notó de inmediato en la implementación de uno de los proyectos.

La única manera de escribir mejor código es escribir más código. Tome un proyecto que haya implementado de manera procesal y conviértalo a POO (suponiendo que esté trabajando en un lenguaje que admita ambos). Probablemente terminará con una solución frágil y estrechamente acoplada la primera vez, pero está bien. Tome la mala implementación de la OOP y comience a refactorizarla en algo mejor. Eventualmente, descubrirás qué funciona y qué no.

Cuando esté listo para dar el siguiente paso, elija un libro de patrones de diseño y aprenda algo de la terminología de diseño de POO. Esto no es estrictamente necesario, pero le dará una mejor comprensión de algunos de los problemas y soluciones comunes.

La mentalidad OO se basa en principios que se encuentran en un nivel mucho más básico que los patrones de diseño. Los patrones de diseño están algo de moda en estos días (y lo han estado por un tiempo), y son útiles, pero son solo una capa más que puedes poner sobre más cosas básicas que debes aprender y dominar si quieres hacer OO correctamente. . En otras palabras: puede hacer OO perfectamente sin patrones de diseño. De hecho, muchos de nosotros hicimos OO mucho antes de que incluso se acuñara la frase "patrones de diseño".

Ahora, hay cosas que no puedes hacer sin ellas. Te sugiero que comiences con lo básico. Lea y comprenda "2da edición de" Construcción de software orientada a objetos "por Bertrand Meyer . Es probablemente el mejor libro sobre programación OO, tanto en ancho como en profundidad. Eso es si estás interesado en la programación .

La parte difícil de OO es qué cosas se deben juntar en un objeto. Como ya mencionó la evolución de su código fuente, aquí tiene una guía simple sobre cómo evolucionar su código fuente hacia un diseño OO:

"Put stuff together that changes together."

Cuando dos piezas de código tienen velocidades de cambio similares, es un indicio de que deben colocarse en el mismo objeto. Cuando las velocidades de cambio son diferentes, considere colocarlas en diferentes objetos.

Esto también se conoce como "velocidad de cambio".

Si sigue esa pauta, su código evolucionará naturalmente hacia un buen diseño OO. ¿Por qué?

Los fragmentos de código a menudo tienen velocidades de cambio similares si acceden a una representación común. Cada vez que la representación cambia, todas las piezas de código que la utilizan deben cambiarse a la vez. Esto es parte de la razón por la que usamos objetos como módulos para encapsular la representación. Separar la interfaz de la implementación también tiene sentido bajo esta guía: la implementación cambia con más frecuencia y, por lo tanto, tiene una mayor velocidad de cambio.
Si una clase tiene una parte estable y una parte inestable, esa es una diferencia en la velocidad de cambio que sugiere mover la parte estable a una clase base (posiblemente abstracta).
De manera similar, si una clase tiene dos partes que cambian con la misma frecuencia pero en diferentes momentos o en diferentes direcciones (es decir, por diferentes razones), eso nuevamente sugiere refactorizar la clase.
A veces reemplaza "clase" con "método". Por ejemplo, si es probable que una línea de un método cambie con más frecuencia que el resto (quizás sea la línea la que crea una nueva instancia de objeto y contiene el nombre de su clase), considere moverla a su propia rutina. Luego, las subclases pueden efectuar fácilmente su cambio al anularlo.

Encontré este concepto en la wiki de C2 hace muchos años , pero rara vez lo he visto usado desde entonces. Me resulta muy útil. Expresa una motivación subyacente crucial del diseño orientado a objetos. Por supuesto, es por lo tanto obvio.

Estos son los cambios del programa. Hay otra sensación de velocidad de cambio: no desea que las variables de instancia cambien a una velocidad diferente, o más bien eso es un signo de problemas potenciales. Por ejemplo, en un editor de gráficos no debe mantener las figuras y los manejadores en la misma colección, ya que las cifras cambian una vez por minuto o una vez por hora y las manijas cambian una vez por segundo o una vez por minuto.
En una vista algo más grande, desea que un sistema pueda cambiar lo suficientemente rápido para mantenerse al día con los cambios en el negocio.

PD: el otro principio que deberías seguir es la "Ley de Deméter", es decir, un objeto solo debe hablar con sus amigos. Los amigos son: usted mismo, variables de instancia, parámetros, locales y miembros de colecciones amigas, pero no variables globales y estáticas.

No lo hagas

Primero, aprende a escribir. En segundo lugar, aprender la experiencia del usuario y el diseño de interacción. En tercer lugar, aprender análisis de negocios. Cuarto, aprender el modelado de roles.

Ahora que sabe qué son los objetos, verá que los objetos no se encuentran en el código. Se encuentran en tiempo de ejecución; en el espacio entre la máquina y la mente del usuario. Esto es lo que realmente significa la orientación a objetos. Desafortunadamente, la academia reciente lo ha convertido en un concepto de ingeniería. Nada podría estar más lejos de la marca. Y trate de emular, el resultado final es una mierda. ¿Por qué? Porque el paradigma "OOP", como lo sabe la industria hoy en día, se basa en una idea fundamentalmente defectuosa: el análisis de la descomposición de la identidad. ¿Cómo es esto defectuoso? Porque la identidad en sí misma no tiene sentido. Es nula En sentido matemático, en sentido filosófico. No es así como un ser humano percibe e interactúa con el mundo.

Canon: Alan Kay, Trygve Reenskaug, James (Jim) Coplien

Cómo me gustaría estar en tu posición. :)

Para mí, el momento ah-ha de OOP fue la primera vez que miré el código y me di cuenta de que podía refactorizar cosas comunes en una clase base. Usted sabe claramente cómo utilizar el código y la reutilización, pero debe pensar en las clases y no en los procedimientos. Con la autenticación del usuario, está claro que va a tener un nombre de usuario y contraseña, ahora ingresan a la clase base, pero ¿qué pasa si también necesita un ID de token, reutilice su clase base de inicio de sesión existente y cree una nueva subclase a partir de eso? Con el nuevo comportamiento, todo su código existente funciona sin cambios.

Mira cómo funciona eso para ti.

Paso 1. Leer un buen libro de patrones de diseño. http://www.oodesign.com/

Paso 2. Elige algo que ya sabes y vuelve a trabajar desde una perspectiva OO. Este es el enfoque del Código Dojo. Tome un problema que ya entiende y defina las clases de objetos.

Hice esto y escribí lo que hice.

Ver http://homepage.mac.com/s_lott/books/oodesign.html#book-oodesign

Puedes hacer la misma serie de ejercicios para entender el diseño y el código de OO.

Podría considerar el uso del enfoque de tarjeta CRC (Clase / Responsabilidad / Colaboración) para el diseño de OO. Esto no es nada aterrador, solo es una forma de ordenar cuáles deberían ser tus objetos, y qué objeto debe ser responsable de las tareas, escribiendo cosas en un montón de tarjetas de archivo para ayudar a aclarar tus pensamientos.

Originalmente fue diseñado como una herramienta de enseñanza para el pensamiento OO, y podría funcionar para usted. El artículo original está en: http://c2.com/doc/oopsla89/paper.html

Un cartel de arriba sugirió la programación en Smalltalk para forzarlo a adoptar hábitos de OO, y hasta cierto punto es una buena sugerencia: Smalltalk ciertamente me hizo mucho bien, pero

a) Es posible que no tenga tiempo libre para aprender un nuevo idioma. Si lo haces, genial.

b) Solía ser tutor de un curso universitario en programación OO, usando Smalltalk, y los estudiantes hicieron un excelente trabajo para demostrar esa vieja broma sobre cómo "Puedes escribir FORTRAN en cualquier idioma".

Finalmente: cuando estaba aprendiendo sobre OO (de los libros) tuve la impresión de que subclasificaste mucho, creando jerarquías de clase complicadas. Cuando comencé a trabajar con programadores OO, me di cuenta de que no sucedía tan a menudo como pensaba. Creo que todos cometen este error cuando están aprendiendo.

Primero, felicidades por tomar pasos para aprender algo nuevo! Odio cuando los desarrolladores deciden NO evolucionar con la tecnología.

En cuanto a pasar de la programación de procedimientos a la POO, diría que una cosa que puede hacer es tomar una aplicación existente (como han mencionado otros) y, antes de abrir un editor de texto, siéntese y piense cómo cada aspecto de La aplicación se convertiría. Descubrí que más de la mitad de la programación OO es definir primero los objetos conceptuales en su mente.

Una vez más, estaré de acuerdo con las recomendaciones de todos sobre los patrones de diseño. Específicamente, observaría el patrón MVC (Modelo-Vista-Controlador) ya que este podría ser el más fácil de comprender. Ya ha escrito un código, por lo que debería poder ver sus aplicaciones existentes y comenzar a colocar cada parte en las categorías M, V o C.

Buena suerte y diviértete!

Simplemente practica. Si ha leído todo sobre OOP y sabe algo sobre OOP y conoce los principios de OOP implementados en su lenguaje PHP ... entonces practique, practique y practique un poco más.

Ahora, no veas OOP como el martillo y todo lo demás como el clavo, pero trata de incorporar al menos una clase en un proyecto. Luego ve si puedes reutilizarlo en otro proyecto, etc.

Un gran paso sería comenzar con un marco OOP, aún puede escribir código de procedimiento en el marco, pero con el tiempo puede refinar sus hábitos de codificación y comenzar a convertir la funcionalidad en objetos.

Además, leer sobre patrones y modelos de datos te dará más ideas para codificar tu lógica en un estilo OOP.

Ya hay bastantes respuestas sobre dónde encontrar información sobre programación en una forma orientada a objetos. De hecho, hay muchos libros geniales por ahí que definirán los conceptos básicos, sin embargo, creo que la pregunta era más sobre cómo "mantenerlo" a través del desarrollo para alguien nuevo en el método.

De los muchos conceptos en la programación orientada a objetos, el principal que lo mantendrá en el buen camino como recién llegado es la encapsulación. ¿Sabe mi clase cómo cuidarse solo? ¿Mi clase tiene comportamiento? Si no es así, entonces no tienes una clase, tienes una estructura y es probable que estés escribiendo muchos procedimientos para cambiar su estado (como se dice, "estás de vuelta para escribir C en Java") . ¿Mi clase solo expone públicamente los métodos que se requieren para su uso? Es posible que esas preguntas no estén muy elaboradas, pero tal vez considere este experimento mental al diseñar sus clases: ¿Qué pasaría si cada una de las aplicaciones de su aplicación fuera desarrollada y mantenida por un desarrollador diferente en Internet y las clases también tuvieran que interactuar entre sí a lo largo de La Internet. ¿Cada desarrollador estaría de acuerdo en que la clase que están escribiendo y manteniendo se adhiere al principio de responsabilidad única y, por lo tanto, estaría feliz de no mantener lo que debería ser el código de otra persona?

Con respecto al diseño de las interfaces de clase, considere escribir todo el código que usa sus clases primero. No te preocupes por lo que tiene que pasar en el metal todavía. Debería poder apagar todo el programa en términos de las relaciones de clase antes de escribir su primer detalle de implementación de twiddling de bits. Si no puede hacer esto sin tener que cambiar los bits o hacer pública una variable, entonces es hora de volver al diagrama de relaciones de clase y ver si falta una abstracción. Expresado de otra manera, usa tu código antes de escribirlo . Haga esto primero y se sorprenderá de lo limpio que resulta su código e interfaces si nunca lo ha hecho antes.

Si bien los patrones de diseño son ciertamente buenos para aprender, y algunos son extremadamente poderosos, generalmente no están intrínsecamente orientados a objetos y, como algunos argumentan (y tiendo a estar de acuerdo), los patrones de diseño son a menudo simplemente puntos débiles en el lenguaje. Los patrones de diseño de una lengua son los principios básicos de otra. Entonces, al comenzar, no se preocupe por si alguna relación es o no un buen candidato para un puente o una fachada; Esto no es específico del pensamiento orientado a objetos, sino que está relacionado con lo que permiten las construcciones de un lenguaje específico.