tipos software programacion patrones orientado orientada objetos ejemplos donde diseño aplicaciones aplica design oop architecture

design - software - Recomendaciones sobre cómo hacer el diseño de OOP



programacion orientada a objetos y sus aplicaciones (15)

Me parece que cada vez que comienzo a escribir una aplicación en Java / C #, las cosas comienzan bien, pero con el tiempo, a medida que la aplicación se vuelve más compleja, se vuelve cada vez más complicada. Me he dado cuenta del hecho de que no soy muy bueno en diseño y arquitectura de alto nivel. Todas mis clases se acoplan bastante fuertemente y el diseño no es "elegante" en absoluto. Soy bastante competente en la programación de "bajo nivel". Es decir, puedo hacer prácticamente cualquier cosa dentro de una función o clase, pero mi diseño de alto nivel es débil y realmente me gustaría mejorarlo. ¿Alguien tiene consejos sobre técnicas, libros, etc. que serían útiles para hacerme un mejor ingeniero de software?

Comenzaría esbozando mi diseño. Ese boceto podría ser un cuadro y un diagrama de flecha para mostrar las relaciones entre las clases o podría ser una variación en UML (o quizás incluso UML estándar). Pero me parece que los bocetos me ayudan a ver que un diseño es bueno / malo y tal vez incluso cómo solucionarlo.

También miraría un libro sobre patrones de diseño.

Escribe un proyecto grande y deja que se extienda lo más posible. Luego, estudie qué puede hacer para mejorar su código.

Quizás las grandes rutinas individuales también pueden ser limpias y comprensibles si están bien estructuradas.

No hay una sola buena respuesta para un buen diseño. En realidad, es una de esas cosas valiosas que un programador puede aprender.

Hay un par de cosas que puedes hacer

  1. Use herramientas para el diseño de alto y bajo nivel antes de comenzar a programar. Por ejemplo, la creación de diagramas UML de clase le ayudará a su mente a visualizar la solución en forma de Diagrama en lugar de forma de Código.

  2. Familiarízate con los patrones de diseño de Java . Por ejemplo, usar herencia de forma polimórfica, para empezar, lo calentará para comenzar a utilizar los patrones de diseño estándar de Java y J2EE.

Hay una tonelada de libros y sitios web relacionados con los dos temas que acabo de señalar aquí.

Intente hacer esquemas y diagramas de programas antes de comenzar, y pida a alguien más que lo revise y lo critique. Luego, a medida que el programa crezca, actualice continuamente los contornos y diagramas para incluir la nueva funcionalidad. Recíbelo y critíquelo por otra persona. Eventualmente, asumiendo que estás aprendiendo de las críticas, serás mejor en el diseño de programas.

Los libros y tutoriales solo pueden llevarlo hasta ahora. Si bien necesitas aprender las herramientas y métodos disponibles, el conocimiento por sí mismo no te ayudará aquí. La práctica es lo que lo hará mejor en el diseño, junto con tener un mentor que de vez en cuando le mostrará cómo puede aplicar mejor algunos de los conocimientos que ha obtenido de los libros.

Lea los libros por todos los medios, pero no se sienta mal si escribe un código que termine teniendo estupideces. Todo el mundo lo hace. La pregunta es, ¿puedes refactorizar lo que tienes que arreglar? Para poder hacer eso de manera efectiva y con frecuencia, necesita usar TDD y escribir muchas pruebas unitarias.

Navega a través del buen código API. Por ejemplo, el código de marco Spring. Lea algunos buenos libros como Design Patterns (como todos los demás mencionados aquí) y algunos otros libros sobre buenas prácticas. Por ejemplo, en Java, Head First Design, Effective Java series, etc. C ++ - Effective C ++ series

Obviamente, leer algunos de los libros recomendados ayudará. Creo que Head First Design Patterns es definitivamente menos abstracto que el libro de GoF.

La pregunta principal que hago es "¿Este código está haciendo algo muy específico que podría reutilizarse en cualquier otro lugar?" Si es así, colóquelo en una clase en un conjunto que permita la reutilización.

Si realmente estás empezando, una cosa que solía hacer era considerar cada tabla de base de datos como un ''objeto''. Entonces, cada tabla de base de datos representa una clase. Los puristas te dirán que esto es un desastre, pero me pareció una buena manera de empezar a pensar en términos objetivos.

Puede refactorizar sin piedad para mejorar el diseño del código existente.

La idea principal es que, en algún momento, el código tenía sentido, cuando se introducen nuevas características en el código, entonces probablemente algunas características o responsabilidades se deben trasladar a otras clases, está bien. Luego dejas de desarrollar nuevas funciones y comienzas a cambiar la forma de tu código.

Te recomendaría que leyeras:

Refactorización por Martin Fowler

Recomiendo mucho que pruebes Test Driven Development (TDD). Descubrirá que para que su código sea comprobable y no necesite realizar repetidamente la reelaboración de sus pruebas, deberá tener un diseño sólido. Lo que encontrará es que cuando agrega / change / remove funcionalidad, sus mejores diseños requerirán un conjunto muy pequeño de cambios en un conjunto específico de pruebas. Un diseño deficiente borrará un gran conjunto de pruebas, porque tiene un acoplamiento ajustado, objetos responsables de múltiples preocupaciones, etc., etc.

Descubrí que cuanto mejor recibo en TDD, mejor es mi arquitectura y mejor es el resultado final.

Tenga en cuenta que TDD requiere una verdadera disciplina mental. No debe esperar que lo use durante 1-2 días y ver resultados inmediatos. Tendrá que querer hacerlo realmente, y realmente hacer el esfuerzo; de lo contrario, no se beneficiará y probablemente termine odiando.

HTH ...

Libros:

  • Code Complete, por Steve McConnel
  • Patrones de diseño, por Gamma, et. Alabama.

No estoy de acuerdo con comenzar con un libro sobre patrones de diseño o refactorización.

En mi opinión, para un diseño de OO sólido, primero debe estar familiarizado con los principales principios de diseño de OO, luego comprender cómo su problema puede ser representado en esos principios básicos. Luego, puede comenzar a descubrir oportunidades para aplicar patrones de diseño y técnicas de refactorización para alcanzar esos principios fundamentales.

Comenzaría con este libro:

Desarrollo ágil de software, principios, patrones y prácticas por Robert C. Martin

En este libro, Robert Martin describe los principios fundamentales que hacen un buen diseño de OO, todos ellos relacionados con la encapsulación, el acoplamiento y la modularidad:

  • El principio abierto / cerrado
  • Liskov Sustitución
  • Inversión de Dependencia
  • Granularidad
  • Cierre común
  • Reutilizar
  • Sin dependencia cíclica
  • Estabilidad de Dependencia
  • Abstracción y estabilidad

Después de todo, casi todas las técnicas de diseño y refactorización que he visto documentadas en GoF y Fowler apuntan a alcanzar uno de varios de estos principios básicos, dependiendo de su prioridad relativa para un escenario dado.