Recomendaciones sobre cómo hacer el diseño OOP

Question

Me parece que cada vez que empiezo 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 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?

Answer 1

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 vería un libro sobre patrones de diseño.

Answer 2

Libros:

• código completo, por Steve McConnell
• patrones de diseño, por Gamma, et. Alabama.

Answer 3

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.

Answer 4

La respuesta a su pregunta podría llenar un libro por sí misma, pero le sugiero que eche un vistazo a los patrones de diseño.

El libro clásico sobre el tema se conoce como el libro "banda de los cuatro":

Gang of Four Design Patterns Book

Martin Fowler es también muy apreciada en el campo.

Answer 5

Pruebe hacer esquemas y diagramas del programa 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 ayudarlo hasta el momento. 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.

Answer 6

Lea los libros por todos los medios, pero no se sienta mal si escribe un código que termine teniendo estupideces en él. 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.

Answer 7

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 mover a otras clases, eso está bien. Luego dejas de desarrollar nuevas funciones y comienzas a cambiar la forma de tu código.

Yo recomendaría que lea:

Refactoring by Martin Fowler

Answer 8

Yo recomendaría encarecidamente que probar 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.,

He descubierto que cuanto mejor recibo en TDD, mejor es mi la arquitectura es, y mejor es el resultado final.

Tenga en cuenta que TDD requiere una gran 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 ...

Answer 9

Hay un par de cosas que usted puede hacer

1. Use herramientas de alto nivel y de bajo nivel de diseño antes de empezar programación. P.ej. Creación de diagramas UML de clase ayuda a su mente a visualizar la solución en forma de diagrama más bien que forma de código.

2. Familiarícese con Java Patrones de diseño. P.ej. Usar Herencia polimórficamente para comenzar con lo calentará para comenzar a usar los patrones estándar de diseño Java y J2EE patrones.

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

Answer 10

usa Principios de diseño orientados a objetos (http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm). también considere algunos de los diseños de heursitics (http://www.cs.colorado.edu/~kena/classes/6448/s02/lectures/lecture27.pdf)

Answer 11

Examine mediante un 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, serie Effective Java, etc. C++ - Serie C++ efectiva

Answer 12

Obviamente, leer algunos de los libros recomendados ayudará. Creo que Head First Design Patterns es definitivamente menos abstracto que el libro 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 ensamblaje que permita la reutilización.

Si realmente está comenzando, una cosa que solía hacer era considerar cada tabla de base de datos como un 'objeto'. tabla 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.

Answer 13

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 b 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.

Me gustaría empezar con este libro:

Agile Software Development, Principles, Patterns, and Practices por Robert C. Martin

En este libro, Robert Martin describe el fundamental principles que hacen un buen diseño orientado a objetos, todos ellos relacionados con la encapsulación, el acoplamiento y modularidad:

• El Abierto/cerrado Principio
• Liskov Sustitución
• Dependencia Inversion
• Granularidad
• Cierre Común
• reutilización
• Sin cíclica Dependencia
• Estabilidad de la dependencia
• la abstracción y la estabilidad

Después de todo, casi todos los del diseño del modelo y la técnica Refactoring He visto documentado en GoF y Fowler tiene como objetivo lograr uno de varios de estos principios básicos, dependiendo de la ir prioridad relativa para un escenario dado.

Answer 14

Me gustaría empezar con: Head first object-oriented analysis and design. y una vez que dominado: Head first design patterns.

Answer 15

Leer Head First Design Patterns.