Me di cuenta de que tengo dificultades para crear diseños OOP. Pasé mucho tiempo decidiendo si esta propiedad está configurada correctamente en clase X.
Por ejemplo, esta es una publicación que tiene algunos días: enlace
No estoy convencido de mi código. Así que quiero mejorar mis diseños, tomarme menos tiempo en crearlos.
¿Cómo aprendiste a crear buenos diseños? ¿Algunos libros que me puedas recomendar?
Diseñar sistemas es una de las cosas en las que solo puedes mejorar haciendo cosas. Por supuesto, ayuda un poco leer sobre un buen diseño: el libro de diseño general orientado a objetos recomendado es el diseño de Gang of Four. Patrones: 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 converse con ellos, centrándose en por qué tomó las decisiones que tomó. A medida que vaya implementando la solución, notará otros problemas con su diseño. Toma nota de estos y aprende de ellos. También podría ser una buena idea trabajar con otras personas para revisar la implementación comparándola con el diseño y los requisitos, y tener una discusión crítica de las razones por las que hizo las cosas que hizo.
Aunque normalmente me parece mejor sentarme con otras personas cara a cara, aquí se pueden hacer preguntas específicas sobre diseño en Programadores. También hay sitios de Stack Exchange para revisiones de código y implementación preguntas.
Por el aspecto de la pregunta de la vista de código que hiciste, estás en la etapa de exagerar. Creo que es un problema bastante común entre las personas que descubren la importancia de un buen diseño.
En realidad, es un paso natural y probablemente incluso necesario con cualquier habilidad que recojas. A medida que comienza a aprender algo, cuanto más avance en el conocimiento de una habilidad y cuanto más la aplique, mejores serán sus resultados y parecerá que se dirigió directamente al dominio. El problema es que su nuevo objetivo no se convierte en la calidad de sus resultados, sino en la cantidad de conocimientos 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 manera de desarrollar tal comprensión. Claro, puedes leer sobre esto, pero leer no es un sustituto para la experiencia.
Por un lado, leer sobre patrones de diseño es un mal comienzo, IMHO. Leer sobre los principios de diseño de OO, como SOLID y GRASP es mejor. Después de familiarizarse con ellos, el estudio de patrones de diseño comunes es una buena idea, ya que verá cómo esos principios pueden aplicarse para formar modismos concretos.
Se afirma que cuando los patrones emergen en el uso de un idioma, entonces el lenguaje en realidad carece de una característica. Si bien esta afirmación es muy radical, hay mucha verdad en ella. Por lo tanto, sugiero que mire y juegue con otros idiomas para obtener una mejor comprensión de los conceptos que desea emplear y también para aprender sobre nuevos conceptos. Una lista sería Squeak, Ruby y Lisp.
En cuanto a la Lista, mi recomendación personal es Estructura e interpretación de los programas de computadora , que me enseñó mucho sobre diseño, al mostrarme cómo se puede crear soluciones sólidas para problemas complejos sin esfuerzo, con poco más que una abstracción clara y (de) composición de manera descendente.
Así que esto es lo que sugiero:
Como han mencionado otros, solo te volverás bueno con la práctica y la experiencia. Realmente no hay mucho de un atajo que puedas tomar.
El hecho de que mires atrás a tus cosas y no te guste lo que has escrito, ya te pone por delante de la curva en comparación con muchas otras personas en nuestra profesión. Mientras intentas superarte, el resto de nosotros trabajamos con personas que escriben una función de 500 líneas con 20 parámetros, todos pasaron por referencia y 15 de ellos están [dentro / fuera] y esas personas piensan que son la bomba. porque tienen ese lío para trabajar.
Cuando se trata de diseño de software, no es blanco y negro, ya sea que el diseño sea bueno o malo. No importa cuánta experiencia tengas, regresarás a tu antiguo código y pensarás: "¿qué estaba fumando cuando escribí esto?" La clave es la evaluación constante de las cosas y con frecuencia pasar por los ejercicios de pensamiento para evaluar lo que hace que el código bueno sea bueno y el 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 perspectivas diferentes que quizás no hayas considerado.
Para empezar yo recomendaría estos libros:
El diseño frontal nunca es tan bueno como el diseño exterior. Solo prueba, codifica, y refactoriza. Cuando las cosas son feas y no está seguro de cómo limpiarlas, entonces vea si algún patrón de diseño lo ayudará. Practique esto por un tiempo y pronto otros desarrolladores le preguntarán cómo puede crear diseños tan limpios.
Lea otras preguntas en las etiquetas object-oriented design