¿Cómo practicar la programación orientada a objetos? [cerrado]

Siempre he programado en lenguajes de procedimiento y actualmente me estoy moviendo hacia la orientación a objetos. El principal problema al que me enfrento es que no puedo ver una forma de practicar la orientación a objetos de manera efectiva. Explicaré mi punto. Cuando aprendí PHP y C fue bastante fácil de practicar: solo era cuestión de elegir algo y pensar en un algoritmo para esa cosa.

En PHP, por ejemplo, era cuestión de sentarse y pensar: "bueno, solo para practicar, permítanme crear una aplicación con un área de administración donde la gente pueda agregar productos". Esto fue bastante fácil, era cuestión de pensar en un algoritmo para registrar algún usuario, iniciar sesión en el usuario y agregar los productos. Combinando esto con las características de PHP, fue una buena forma de practicar.

Ahora, en orientación a objetos, tenemos muchas cosas adicionales. No se trata solo de pensar en un algoritmo, sino de analizar los requisitos más a fondo, escribir casos de uso, descubrir diagramas de clases, propiedades y métodos, configurar la inyección de dependencia y muchas cosas más.

El punto principal es que, en la forma en que he estado aprendiendo la orientación a objetos, parece que un buen diseño es crucial, mientras que en lenguajes de procedimiento una idea vaga fue suficiente. Estoy no decir que en las lenguas de procedimiento se puede escribir un buen software sin diseño, sólo que por el bien de la práctica es factible, mientras que en la orientación a objetos que no parece factible que ir sin un buen diseño, incluso para la práctica.

Esto parece ser un problema, porque si cada vez que voy a practicar necesito averiguar toneladas de requisitos, casos de uso, etc., parece que no es una buena manera de mejorar la orientación de los objetos, porque esto requiere Me gustaría tener una idea completa para una aplicación cada vez que voy a practicar.

Por eso, ¿cuál es una buena manera de practicar la orientación a objetos?

Ahora, en orientación a objetos, tenemos muchas cosas adicionales.

No, no lo haces ...

No se trata solo de pensar en un algoritmo, sino de analizar los requisitos más a fondo, escribir casos de uso, descubrir diagramas de clases, propiedades y métodos, configurar la inyección de dependencia y muchas cosas más.

Ninguna de esas cosas es necesaria para practicar la programación orientada a objetos.

Esto fue bastante fácil, era cuestión de pensar en un algoritmo para registrar algún usuario, iniciar sesión en el usuario y agregar los productos.

Toda la programación orientada a objetos es, en lugar de pensar en los algoritmos para realizar estos pasos, usted piensa qué objetos se necesitan para realizar estos pasos: qué funcionalidad desea, qué estado se necesita para hacer eso y qué tipo de interfaz desea exponer al usuario Al igual que tienes que hacer en la programación de procedimientos.

La única diferencia es que en lugar de enfocarse en las funciones que necesita y cómo funcionan, se enfoca en cómo la funcionalidad y el estado se agrupan en responsabilidades, y cómo interactúan esas responsabilidades.

¿Cómo practicar? De la misma manera que practica la programación de procedimientos: elija un problema y resuelva el problema utilizando paquetes de clases. Averigua cómo apesta, repite con las lecciones aprendidas.

Buena pregunta. Por supuesto, lo que está diciendo es que practicar OOP en realidad significa practicar todas estas cosas (análisis de requisitos, casos de uso, patrones de diseño, etc.), lo cual es cierto y puede parecer desalentador al principio.

Mi consejo sería comenzar sus sesiones de práctica teniendo en cuenta dos cosas: el desarrollo basado en pruebas y el principio de responsabilidad única .

Luego, comience como lo hizo con PHP / C: tenga una idea, piense en lo que necesita para eso e implemente estas cosas una tras otra. Sin embargo, tenga en cuenta que debe comenzar desde las pruebas (lo que le obliga a definir interfaces adecuadas, ya que de lo contrario la capacidad de prueba se ve afectada de inmediato) y que TDD implica un ciclo de refactorización rojo-verde. En otras palabras, tiene un poco de funcionalidad, y una vez que está funcionando, refactoriza para obtener un diseño OO adecuado si no lo logró desde el principio (lo que no hará).

Cuando realice este paso de refactorización, recuerde siempre el SRP. Si agregó una segunda responsabilidad a su objeto, es hora de crear algo nuevo.

Cuando desarrolle de esta manera, debe ser consciente de que su solución final será muy diferente de la que comenzó. Su curva de aprendizaje también será bastante empinada. Por ejemplo, no aprenderá qué es un patrón Factory, sino que reconocerá la necesidad de algo que cree instancias de su clase de diferentes maneras. Entonces, si no ha oído hablar de los patrones de diseño orientados a objetos, es bueno leer un poco en paralelo.

Si recién está comenzando en OOP, puede divertirse y "practicar" sin conexión al observar casi cualquier sistema del mundo real y considerar cuáles son los objetos y cuál es la relación entre ellos y qué métodos / interfaces pueden admitir y cómo los representaría en una jerarquía de clases y como una colección de objetos instanciados y cuáles serían las relaciones de propiedad del objeto, etc. (nota: no menciono la palabra "algoritmos" en lo anterior). Dibuje muchos diagramas (aprenda un poco de UML o similar) antes de pensar en codificar cualquier cosa.

Esto lo ayudará a desarrollar un sentido mucho mejor de las relaciones IS-A y HAS-A , que es probablemente la clasificación más importante en cualquier diseño OOP (y a pesar de eso, todavía parece ser algo con lo que muchos programadores experimentados de lenguaje OOP luchan) ) Si dominas IS-A / HAS-A también hay IS-IMPLEMENTED-IN-TERMS-OF (que también he visto descrito como IS-KIND-OF-A: ^)

En serio, el próximo viaje al supermercado, imagínense que alguien le ha dado el trabajo de escribir una simulación OOP del lugar ...

Lo que recuerdo de mis tiempos en C (muy atrás en el pasado), solíamos separar funciones y procedimientos en diferentes archivos según su responsabilidad. No estoy afirmando que sea perfecto ni nada, pero fue un buen punto de partida para cuando realmente comencé a programar en lenguajes orientados a objetos. Entonces, tal vez, podría comenzar con la conversión de archivos a objetos.

En lo que respecta a la POO, se trata realmente de practicar y esforzarse por mejorar. Rara vez alguien lo entiende desde cero. Por lo tanto, las iteraciones ocurren a lo largo del ciclo de vida del proyecto.

Agreguemos algo de terminología, análisis orientado a objetos y diseño orientado a objetos , como hizo Peter Coad en la década de 1990.

Juntos, estos forman una disciplina de ingeniería de software OOAD que puede (hecho bien) apoyar al programador en el momento de escribir y probar el código. La programación orientada a objetos puede tener su nivel de granularidad adecuado, el uso hábil de las características del lenguaje de programación para cumplir con los objetivos funcionales y los requisitos de diseño especificados a nivel de proyecto.

A veces es un proyecto de una sola persona, y luego debes usar todos los sombreros (pero no necesariamente todos al mismo tiempo). Soy un gran admirador del desarrollo basado en pruebas para mis propios proyectos personales (consulte la recomendación de Frank), pero no se trata solo del desarrollo de software orientado a objetos.

En un proyecto de equipo, tener una buena división de responsabilidades es clave para una implementación exitosa. El uso hábil de patrones de diseño orientados a objetos ayuda a la comprensión del equipo al limitar las interfaces visibles necesarias para el análisis, los datos y la lógica empresarial para compartir un marco utilizable.

"bueno, solo para practicar, permítanme crear una aplicación con un área de administración donde la gente pueda agregar productos". Esto fue bastante fácil, era cuestión de pensar en un algoritmo para registrar algún usuario, iniciar sesión en el usuario y agregar los productos.

¿Por qué no hacer lo mismo solo esta vez con objetos de usuario y objetos de producto? Además, si está utilizando un lenguaje que admite procedimientos y OO, podría intentar implementar objetos basados ​​en la biblioteca estándar de procedimientos, como un objeto de archivo.