OOP: buen diseño de clase

Question

Mi pregunta está relacionada con este: Python tool that builds a dependency diagram for methods of a class.

Después de no encontrar ninguna herramienta, escribí un hack rápido: he utilizado el módulo de compilación, he analizado el código fuente en un árbol de fuentes abstractas y lo he recorrido para recopilar dependencias entre los métodos de clase. Mi secuencia de comandos generó un archivo de entrada para graphviz, que se utilizó para generar un gráfico de dependencia que se parece a this.

En este punto me he quedado atascado. Me di cuenta de que no tengo idea de cómo refactorizar la clase para que sea menos complicada. Simplemente no sé a qué debería aspirar. Por ejemplo, en la teoría de las bases de datos relacionales hay un par de reglas simples que se utilizan para llevar una base de datos a una forma normal. ¿Qué hay de una teoría similar sobre el buen diseño de clase (en términos de dependencias entre sus métodos)? ¿Este tema está cubierto en alguna parte para que yo pueda estudiarlo?

Answer 1

Nos seguir los siguientes principios en el diseño de las clases:

• The Single Responsibility Principle: Una clase (o método) deben tener una sola razón para cambiar.
• The Open Closed Principle: Una clase (o método) debe estar abierta para extensión y cerrada para modificación.
• The Liskov Substitution Principle: Los subtipos deben ser sustituibles por sus tipos de base.
• The Interface Segregation Principle: No se debe forzar a los clientes a depender de métodos que no usan. Las interfaces deben pertenecer a los clientes.
• The Dependency Inversion Principle: Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

Editar: Los patrones de diseño son útiles para lograr que su código cumpla con estos principios. Me ha resultado muy útil comprender primero los principios y luego mirar los patrones y comprender cómo los patrones alinean su código con los principios.

Answer 2

A menudo no es posible decir qué es "correcto" o "incorrecto" cuando se trata del diseño de clase. Hay muchas pautas, patrones, recomendaciones, etc. sobre este tema, pero al final del día, en verdad, es mucho sobre la experiencia con proyectos anteriores. Mi experiencia es que lo mejor es no preocuparse demasiado por ello, y mejorar gradualmente su código/estructura en pequeños pasos. Experimente y vea cómo se sienten/parecen algunas ideas/cambios. Y, por supuesto, siempre es una buena idea aprender de los demás. leer un montón de código y analizarlo, tratar de entender :).

Si quiere leer acerca de la teoría, puedo recomendar la aplicación de UML y patrones de Craig Larmanns: una introducción al análisis orientado a objetos y al diseño y desarrollo iterativo 'Amazon. Cubre varias partes de su pregunta, da algunas pautas generales y las muestra usando una aplicación de ejemplo. Me gustó el libro.

¿Podría usted subir su aplicación a alguna parte? Tal vez en Github más o menos, tal vez podría pedir algunos consejos concretos.

Answer 3

Design Patterns se ha convertido en el estándar de facto para un buen diseño de clase. En general, cada patrón tiene un caso de uso particular o escenario al que se aplica. Si puede identificar esto en su código, puede usar el patrón para crear algo que tenga más sentido, y generalmente tiene menos dependencias.

Refactorear es la herramienta que usaría para realizar estos cambios de barrido. Un buen IDE te ayudará a refactorizar.

Answer 4

Intente hacer que cada método sea fácilmente comprobable por unidad. Encuentro que esto siempre impulsa mis diseños hacia una mayor legibilidad/comprensibilidad. Existen numerosas reglas OOAD: SRP, DRY, etc. Trate de tenerlas en cuenta al refactorizar.

Answer 5

Recomiendo el libro "Refactoring" de Martin Fowler para obtener toneladas de ejemplos prácticos de conversión iterativa de diseño pobre a buen diseño.