¿Cómo obtuviste buenas prácticas para tus diseños OOP? [cerrado]

Me di cuenta de que tengo dificultades para crear diseños OOP. Pasé mucho tiempo decidiendo si esta propiedad está configurada correctamente en la clase X.

Por ejemplo, esta es una publicación que tiene algunos días: /codereview/8041/how-to-improve-my-factory-design

No estoy convencido de mi código. Por eso quiero mejorar mis diseños, dedicarme menos tiempo a crearlos.

¿Cómo aprendiste a crear buenos diseños? ¿Algunos libros que me pueden recomendar?

Diseñar sistemas es una de las cosas en las que solo puedes mejorar haciendo. Por supuesto, ayuda un poco leer sobre un buen diseño: el libro de diseño general orientado a objetos recomendado es Patrones de diseño de la cuadrilla de cuatro : elementos de software orientado a objetos reutilizables . También hay otros libros sobre patrones y principios de diseño para diferentes tipos de sistemas y dentro de diferentes dominios.

También es mejor involucrar a otras personas. Después de crear un diseño, presente los problemas que está resolviendo y el diseño a otras personas para una revisión crítica. Escuche sus comentarios y tenga un diálogo con ellos, enfocándose en por qué tomó las decisiones que tomó. A medida que implementa la solución, se dará cuenta de otros problemas con su diseño. Tome nota de estos y aprenda de ellos. También podría ser una buena idea trabajar con otras personas para revisar la implementación en relación con el diseño y los requisitos, y tener una discusión crítica de las razones por las que ha hecho las cosas que hizo.

Aunque normalmente me parece mejor sentarme con otras personas cara a cara, aquí se pueden hacer preguntas específicas de diseño en Programadores. También hay sitios de Stack Exchange para revisiones de código y preguntas de implementación .

Por el aspecto de la pregunta de revisión de código que hizo, está en la etapa de exagerar. Creo que es un problema bastante común entre las personas que descubren la importancia del buen diseño.

En realidad, es un paso natural y probablemente incluso necesario con cualquier habilidad que elijas. A medida que comienza a aprender algo, cuanto más avance en el conocimiento de una habilidad y más la aplique, mejores serán sus resultados y parecerá que se dirige hacia el dominio. El problema es que su nuevo objetivo no se convierte en la calidad de sus resultados, sino en la cantidad de conocimiento que ha acumulado sobre su habilidad.

El verdadero dominio de una habilidad implica la comprensión de cuándo usarla y cuándo no. El uso excesivo de esa habilidad es probablemente la única forma de desarrollar tal comprensión. Claro, puedes leer sobre esto, pero leer no sustituye la experiencia.

Por un lado, leer sobre patrones de diseño es un mal comienzo en mi humilde opinión. Es mejor leer sobre los principios de diseño de OO, como SOLID y GRASP . Después de familiarizarse con ellos, el estudio de patrones de diseño comunes es una buena idea, porque verá cómo esos principios se pueden aplicar para formar expresiones idiomáticas concretas.

Se afirma que cuando surgen patrones en el uso de un lenguaje, el lenguaje carece de una característica. Si bien esta afirmación es muy radical, hay mucha verdad en ella. Por lo tanto, sugeriría que mire y juegue con otros idiomas para obtener una mejor comprensión de los conceptos que está buscando emplear, y también para aprender sobre nuevos conceptos. Una lista corta sería Squeak, Ruby y Lisp.
En cuanto a List, mi recomendación personal es Estructura e interpretación de programas informáticos , que me enseñó mucho sobre diseño, mostrándome cómo sin esfuerzo se pueden crear soluciones sólidas para problemas complejos, con poco más que una clara abstracción y (des) composición en de arriba hacia abajo.

Entonces, esto es lo que sugiero:

1. escribir código (y tratar de entender qué lo hace malo)
2. lee el código (y trata de entender lo que lo hace bueno)
3. intercambiar conocimientos con otras personas. Pon tus ideas a prueba.

Como otros han mencionado, solo mejorarás con práctica y experiencia. Realmente no hay mucho atajo que puedas tomar.

El hecho de que mire hacia atrás y no le guste lo que ha escrito, ya lo pone a la vanguardia en comparación con muchas otras personas en nuestra profesión. Mientras intenta mejorar, el resto de nosotros trabajamos con personas que escribirían una función de 500 líneas con 20 parámetros, todos pasados ​​por referencia y 15 de ellos siendo [dentro / fuera] y esas personas piensan que son la bomba porque consiguieron ese desastre para trabajar.

Cuando se trata de diseño de software, no es en blanco y negro, el diseño es bueno o malo. No importa cuánta experiencia tenga, volverá a su antiguo código y pensará: "¿Qué estaba fumando cuando escribí esto?" La clave es la evaluación constante de las cosas y, a menudo, pasar por los ejercicios de pensamiento para evaluar qué hace que un código bueno sea bueno y que un código malo sea malo.

Finalmente, aunque nada reemplaza la práctica, siempre es una buena idea seguir leyendo blogs / libros / este sitio porque otras personas señalarán diferentes perspectivas que quizás no haya considerado.

Para comenzar, recomendaría estos libros:

• Principios, patrones y prácticas ágiles en C # : yo mismo estoy en 3/4 de este libro. Uno de los puntos principales que señala el autor, y estoy 100% de acuerdo con eso, no empiece a resolver un problema buscando un patrón de diseño para aplicar. Mantenga las cosas lo más simple posible y desarrolle el código en un patrón, si la alternativa comienza a ser más complicada que eso.
• Patrones de diseño de Head First : no he leído este libro y, en mi opinión, muchas series de Head First están dirigidas específicamente a los recién llegados al campo. Entonces tienden a ser más simples, pero he escuchado / leído muchas buenas respuestas de otros sobre ese libro

El diseño frontal nunca es tan bueno como el diseño exterior. Solo prueba, codifica y refactoriza. Cuando las cosas están feas y no estás seguro de cómo limpiarlo, entonces mira si algún patrón de diseño te ayudará. Practique esto por un tiempo y pronto otros desarrolladores le preguntarán cómo se le ocurren diseños tan limpios.