¿Cómo saber realmente qué se debe hacer en el diseño orientado a objetos?

12

Primero, un descargo de responsabilidad: no sé si esta pregunta se ajusta a este sitio web, pero me parece una pregunta relevante no solo para mí, sino también para otras personas que son principiantes. Si la pregunta se puede mejorar para que encaje aquí, señale los comentarios. Si no encaja, hágamelo saber también y, si es posible, hágame saber dónde se puede discutir esto porque no encontré ningún buen foro para esto.

Aprendí a programar en 2009 cuando estudié PHP. Más tarde, en 2012, me mudé a C # y .NET. De todos modos, la codificación no es el problema, escribir algoritmos no es mi problema. Mi problema real es saber qué se debe codificar para lograr un requisito y dónde se debe codificar.

La mayoría de los cursos disponibles en la web abordan el cómo : cómo escribir código en un idioma determinado, cómo usar algunos conjuntos de API, etc. Ese no es mi punto aquí.

En estos años he leído mucho sobre un montón de cosas: análisis y diseño orientados a objetos, patrones de diseño, diseño basado en dominios, etc. Entiendo, por ejemplo, los principios SÓLIDOS, algunas de las ideas principales de DDD como la necesidad de participación de expertos en dominios, el desarrollo de un lenguaje ubicuo, etc. Me atrevería a decir que tengo un fondo teórico al menos razonable.

Pero cuando se trata de practicar, siento que soy un desastre. Hace algún tiempo necesitaba continuar con el desarrollo de un sistema financiero que ya estaba siendo desarrollado por otra persona. Es ese tipo de "sistema antiguo" desarrollado con C # y WinForms. Fue la primera vez que elegí un proyecto con una complejidad de dominio real, con muchas reglas de negocios, etc.

Confieso que cuando recibo los requisitos la mayor parte del tiempo pienso "cómo se puede hacer esto?" - No tengo ni idea de cómo empezar a trabajar en los requisitos para averiguar qué se debe hacer. Creo que mis principales confusiones son lo que debo codificar, qué clases, interfaces y dónde va cada lógica, en qué clase debe estar cada cosa. El problema es que no sé por dónde empezar.

La mayoría de las veces, con bastante pensamiento termino con algunas ideas, pero nunca sé cómo juzgar si mi idea es correcta o no.

Quiero decir, no creo que esto sea una falta de teoría, ya que dije que había leído un montón de cosas sobre arquitectura de software y orientación a objetos. Me recomendaron pero no ayudó mucho a identificar lo que debe ser. hecho en la práctica.

Entonces, ¿cómo puedo aprender a realmente hacer el diseño orientado a objetos? Lo que quiero aprender es: dados los requisitos, saber cómo comenzar a trabajar en ellos en un proceso que lleva a descubrir qué se debe hacer y a dónde pertenece cada pieza de código. ¿Cómo puedo aprender a juzgar si mi idea es correcta o no?

Creo que explicar esto como una respuesta aquí no sería posible. Lo que estoy buscando, sin embargo, que puede estar de acuerdo con el estilo del sitio son respuestas que solo dan una visión general y señalan algunas referencias (libros, cursos en línea, etc.) que se pueden usar para expandir las ideas y realmente aprender estas cosas. p>     

pregunta user1620696 07.05.2017 - 00:35

2 respuestas

21
  

Entonces, ¿cómo puedo aprender a hacer realmente el diseño orientado a objetos? Lo que quiero aprender es: teniendo en cuenta los requisitos, saber cómo comenzar a trabajar en ellos en un proceso que lleva a descubrir qué se debe hacer y a dónde pertenece cada pieza de código. ¿Cómo puedo aprender a juzgar si mi idea es correcta o no?

Primero que nada, deja de pensar en el diseño orientado a objetos como correcto. Es como pensar que el inglés es correcto.

El paradigma orientado a objetos no es correcto. Tiene ciertas ventajas y desventajas. Es un ideal. No es nuestro único. Es mejor que nada, pero ciertamente no lo es todo.

He estado codificando durante décadas ahora. He estudiado esto durante casi todo el tiempo que han existido las ideas. Todavía estoy aprendiendo lo que significa. Los expertos todavía están aprendiendo lo que significa. Todo nuestro campo tiene menos de 100 años.

Entonces, cuando tomas un montón de requisitos y obtienes un código que los satisface, sientes que el código que escribiste es un desastre trágico, no estás solo. Código de trabajo es simplemente el primer paso para un gran código. Código que no solo funciona sino que otros pueden leer y entender fácilmente. Código que puede adaptarse rápidamente cuando cambian los requisitos. Código que te hace querer sentarte y decir "Wow, eso es tan simple".

El problema es que no nos pagan por hacer todo eso. Hacemos todo eso porque somos profesionales. Tenemos que hacer todo eso cuando el jefe no está mirando porque siempre hay una fecha límite. Pero queremos volver en 5 años y decirles a los novatos: "Oh, sí, escribí eso. ¿Todavía funciona eh? Genial".

¿Cómo llegas allí? Práctica. No aceptes NINGUNA idea de diseño en la fe. ¿Alguien no se callará sobre cómo el diseño dirigido por eventos simplificará este diseño? ¿No estás seguro de si tienen razón? Construye tu propio proyecto de juguete en casa que usa el patrón de observador. Lío con él. Trate de encontrar cosas con las que NO ayude.

Leer. Pregunta. Prueba. Repetir.

Cuando llegues al punto en que lo has estado haciendo durante el 80% de tu vida, estarás tan confundido como yo.

  

Confieso que cuando recibo los requisitos la mayor parte del tiempo pienso "cómo se puede hacer esto?" - No tengo ni idea de cómo empezar a trabajar en los requisitos para averiguar qué se debe hacer. Creo que mis principales confusiones son lo que debo codificar, qué clases, interfaces y dónde va cada lógica, en qué clase debe estar cada cosa. El problema es que no sé por dónde empezar.

Solía sentir lo mismo. Entonces descubrí la alegría de refactorizar. Esté dispuesto a adaptar diseños a medida que codifique. Tratar de resolver todo en papel antes de tiempo es la manera más difícil de hacerlo. Escriba un código que pueda demostrarse incorrecto, demuestre que está equivocado y corríjalo.

    
respondido por el candied_orange 07.05.2017 - 02:50
1

El desarrollo de software se reduce a la entrega del software en funcionamiento, a tiempo, dentro del presupuesto y cumpliendo con todos sus criterios de aceptación. Suponiendo que haya logrado hacerlo, la calidad percibida del código o su estructura es una preocupación secundaria.

El problema, por supuesto, es que escribir un nuevo código de código nuevo tiende a ser mucho más barato y más fácil que mantener el código heredado, por lo que, en lugar de estar demasiado obsesionado con la arquitectura o la calidad del código, recuerde que su problema real es la capacidad de mantenimiento.

Normalmente, el código se considera mantenible cuando los costos, el tiempo y los riesgos asociados con el cambio de ese código son proporcionalmente bajos, por lo que la solución de errores o la implementación de cambios a los requisitos sigue siendo rentable, y al implementar esos cambios no se perpetúa una "Espiral de la muerte" del código-entropía.

A la inversa, el código se considera no mantenible cuando no se puede cambiar o refactorizar con confianza sin un riesgo grave de romper algo o gastar un tiempo / dinero excesivo para garantizar que no se rompa nada, es decir, cuando es el momento. el costo y el riesgo que implica trabajar con ese código es desproporcionadamente alto en comparación con los beneficios de realizar cambios (es decir, su empleador o cliente no está perdiendo dinero al agregar nuevas funciones, corregir errores, etc.)

Recuerde que incluso el desorden de espaguetis más diabólico puede ser mantenible si cuenta con suficientes disposiciones para protegerse contra los cambios de ruptura (aunque estos casos son raros). El problema con el desorden de los espaguetis es que protegerlo contra los cambios de ruptura tiende a ser bastante costoso e ineficiente, especialmente si lo hace de forma retrospectiva.

Tal vez la forma más confiable de asegurarse de haber escrito un código mantenible es escribir (cuando sea razonablemente posible) un conjunto adecuado de pruebas automatizadas al mismo tiempo (al mismo tiempo que aprovecha al máximo cualquier otra herramienta de análisis estático que pueda estar disponible ).

No es necesario que sigas una metodología de desarrollo estricta como TDD / BDD para terminar con suficientes pruebas automatizadas para permitirte refactorizar; solo necesita suficiente para proteger el código contra cambios de ruptura accidentales en el futuro.

Si su código está cubierto por pruebas automatizadas, entonces puede relajarse sobre su diseño y estructura sabiendo que está cubierto por esas pruebas; puede refactorizar agresivamente en una fecha posterior, o incluso tirarlo y comenzar de nuevo.

Esto plantea la pregunta de cómo escribir código fácilmente comprobable; este es típicamente el argumento principal para seguir los principios de SOLID; de hecho, el sello distintivo del código que se adhiere a los principios de SOLID es que es fácil y rentable para escribir pruebas unitarias.

Por supuesto, a veces tampoco tienes tiempo para escribir pruebas unitarias; sin embargo, si ha escrito todo su código teniendo en cuenta la pregunta "¿Cómo escribo las pruebas automatizadas para esto?" (incluso si realmente no implementó esas pruebas), probablemente haya También logró encontrar un diseño que es razonablemente mantenible.

    
respondido por el Ben Cottrell 07.05.2017 - 19:17