Término en programación informática
En programación informática , un olor de diseño es una estructura en un diseño que indica una violación de los principios fundamentales del diseño y que puede afectar negativamente la calidad del proyecto. [1] El origen del término se remonta al término " olor de código " que apareció en el libro Refactoring: Improving the Design of Existing Code de Martin Fowler . [2]
Detalles
Diferentes autores han definido la palabra “olor” de diferentes maneras:
- N. Moha et al.: “Los errores de código y de diseño son soluciones deficientes para problemas recurrentes de implementación y diseño”. [3]
- RC Martin: “Los olores del diseño son los olores del software podrido”. [4]
- Fowler: “Los olores son ciertas estructuras en el código que sugieren (a veces gritan) la posibilidad de refactorización”. [2]
Los olores de diseño indican la deuda de diseño acumulada (una de las dimensiones más importantes de la deuda técnica ). Los errores o las características no implementadas no se contabilizan como olores de diseño. Los olores de diseño surgen de las malas decisiones de diseño que hacen que el diseño sea frágil y difícil de mantener. Es una buena práctica identificar los olores de diseño en un sistema de software y aplicar la refactorización adecuada para eliminarlos y evitar la acumulación de deuda técnica.
El contexto (caracterizado por diversos factores, como el problema en cuestión, el ecosistema de diseño y la plataforma) desempeña un papel importante a la hora de decidir si una determinada estructura o decisión debe considerarse un error de diseño. En general, es adecuado aceptar errores de diseño debido a las limitaciones impuestas por el contexto. Sin embargo, los errores de diseño deben controlarse y gestionarse como deuda técnica, ya que degradan la calidad general del sistema con el tiempo.
Olores de diseño comunes
- Abstracción faltante [1] cuando se utilizan grupos de datos o cadenas codificadas en lugar de crear una abstracción. También se conoce como "obsesión primitiva" [2] y "grupos de datos". [2]
- Abstracción multifacética [1] cuando una abstracción tiene múltiples responsabilidades asignadas. También se conoce como "abuso de conceptualización". [5]
- Abstracción duplicada [1] cuando dos o más abstracciones tienen nombres o implementaciones idénticos o ambos. También se las conoce como "clases alternativas con diferentes interfaces" [2] y "artefactos de diseño duplicados". [6]
- Encapsulación deficiente [1] cuando la accesibilidad declarada de uno o más miembros de una abstracción es más permisiva que la realmente requerida.
- Encapsulación no explotada [1] cuando el código del cliente utiliza verificaciones de tipo explícitas (utilizando instrucciones if-else o switch encadenadas que verifican el tipo del objeto) en lugar de explotar la variación en los tipos ya encapsulados dentro de una jerarquía.
- Modularización rota [1] cuando los datos y/o métodos que idealmente deberían haber estado localizados en una única abstracción se separan y se distribuyen en múltiples abstracciones.
- Modularización insuficiente [1] cuando existe una abstracción que no ha sido completamente descompuesta y una descomposición adicional podría reducir su tamaño, complejidad de implementación o ambos.
- Dependencia circular . Modularización cíclicamente dependiente [1] cuando dos o más abstracciones dependen unas de otras directa o indirectamente (creando un acoplamiento estrecho entre las abstracciones). También conocidas como "dependencias cíclicas". [7]
- Jerarquía cíclica [1] cuando un supertipo de una jerarquía depende de cualquiera de sus subtipos. También se conocen como "ciclos de herencia/referencia". [8]
- Jerarquía no factorizada [1] cuando hay una duplicación innecesaria entre los tipos en una jerarquía.
- Jerarquía rota [1] cuando un supertipo y su subtipo conceptualmente no comparten una relación “ES-UNO”, lo que da como resultado una sustituibilidad rota. También se conoce como “uso inapropiado de la herencia” [9] y “aplicación incorrecta de ES UN”. [10]
Véase también
Referencias
- ^ abcdefghijkl Girish Suryanarayana, Ganesh SG, Tushar Sharma (2014). "Refactorización para el diseño de software con malos olores: gestión de la deuda técnica". Morgan Kaufmann. ISBN 978-0128013977
- ^ abcde Fowler, Martin (1999). Refactorización. Mejora del diseño del código existente. Addison-Wesley. ISBN 0-201-48567-2 .
- ^ N. Moha, Y. Gueheneuc, L. Duchien y A. Le Meur. "Decor: un método para la especificación y detección de códigos y olores de diseño". IEEE Trans. Softw. Eng., 36(1):20–36, enero de 2010.
- ^ RC Martin. Desarrollo de software ágil: principios, patrones y prácticas . Addison-Wesley, 2003.
- ^ Trifu A. "Reestructuración automatizada basada en estrategias de código orientado a objetos". En Actas del 7º taller alemán sobre reingeniería de software (WSR); 2005.
- ^ Stal M. "Refactorización de la arquitectura de software". Tutorial en la conferencia internacional sobre programación orientada a objetos, sistemas, lenguajes y aplicaciones (OOPSLA); 2007.
- ^ Page-Jones M. "Guía práctica para el diseño de sistemas estructurados". 2.ª ed. Prentice Hall; 1988.
- ^ Sefika M, Sane A, Campbell RH. "Supervisión de la conformidad de un sistema de software con sus modelos de diseño de alto nivel". En Actas de la 18.ª conferencia internacional sobre ingeniería de software, ICSE '96, Washington, DC; 1996. págs. 387–96.
- ^ Budd T. "Introducción a la programación orientada a objetos". 3.ª ed. Addison Wesley; 2001.
- ^ Page-Jones M. "Fundamentos del diseño orientado a objetos en UML". Addison-Wesley Professional; 1999.
