Hispanopedia Wiki
Articulo de referencia

Diseño de olor

En programación informática , un olor a 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 negativamen...

Hispanopedia WikiContenido en espanolLectura gratuita

En programación informática , un olor a 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 " code smell" (olor a 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 malos olores del código y del diseño son soluciones deficientes a los problemas recurrentes de implementación y diseño." [ 3 ]
  • RC Martin: "Los malos 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 claman por) la posibilidad de refactorización." [ 2 ]

Los malos olores de diseño indican la deuda técnica acumulada (una de las dimensiones principales de la deuda técnica ). Los errores o las funcionalidades no implementadas no se consideran malos olores de diseño. Estos surgen de decisiones de diseño deficientes que hacen que el diseño sea frágil y difícil de mantener. Es recomendable identificar los malos 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 fundamental a la hora de determinar si una estructura o decisión concreta debe considerarse un defecto de diseño. En general, es aceptable tolerar estos defectos debido a las limitaciones impuestas por el contexto. No obstante, deben ser monitorizados y gestionados como deuda técnica, ya que degradan la calidad general del sistema con el tiempo.

olores comunes en el diseño

  • Abstracción inexistente [ 1 ] cuando se utilizan grupos de datos o cadenas codificadas en lugar de crear una abstracción. También conocida como "obsesión primitiva" [ 2 ] y "grupos de datos" [ 2 ] .
  • Abstracción multifacética [ 1 ] cuando a una abstracción se le asignan múltiples responsabilidades. También conocida como "abuso de conceptualización". [ 5 ]
  • Abstracción duplicada [ 1 ] cuando dos o más abstracciones tienen nombres o implementaciones idénticas, o ambas. También conocidas como "clases alternativas con interfaces diferentes" [ 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 de lo que realmente se requiere.
  • Encapsulación no explotada [ 1 ] cuando el código del cliente utiliza comprobaciones de tipo explícitas (utilizando sentencias if-else o switch encadenadas que comprueban 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 sola abstracción están separados y distribuidos en múltiples abstracciones.
  • Modularización insuficiente [ 1 ] cuando existe una abstracción que no se ha descompuesto completamente, y una descomposición adicional podría reducir su tamaño, complejidad de implementación o ambas.
  • 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 conocida como "dependencias cíclicas". [ 7 ]
  • Jerarquía cíclica [ 1 ] cuando un supertipo en una jerarquía depende de cualquiera de sus subtipos. También conocido como "ciclos de herencia/referencia". [ 8 ]
  • Jerarquía no factorizada [ 1 ] cuando existe duplicación innecesaria entre tipos en una jerarquía.
  • Jerarquía rota [ 1 ] cuando un supertipo y su subtipo no comparten conceptualmente una relación "ES UN" que resulta en una sustituibilidad rota. También conocida como "uso inapropiado de la herencia" [ 9 ] y "aplicación incorrecta de ES UN" [ 10 ].

Véase también

Referencias

  1. 1 2 3 4 5 6 7 8 9 10 11 12 Girish Suryanarayana, Ganesh SG, Tushar Sharma (2014). "Refactoring for software design smells: Managing technical debt". Morgan Kaufmann. ISBN 978-0128013977
  2. 1 2 3 4 5 Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.
  3. ↑ N. Moha, Y. Gueheneuc, L. Duchien y A. Le Meur. «Decor: Un método para la especificación y detección de olores de código y diseño». IEEE Trans. Softw. Eng., 36(1):20–36, enero de 2010.
  4. ↑ RC Martin. Desarrollo ágil de software: principios, patrones y prácticas . Addison-Wesley, 2003.
  5. ↑ Trifu A. "Reestructuración automatizada de código orientado a objetos basada en estrategias". En Actas del 7º taller alemán sobre reingeniería de software (WSR); 2005.
  6. ↑ 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.
  7. ↑ Page-Jones M. "Guía práctica para el diseño de sistemas estructurados". 2.ª ed. Prentice Hall; 1988.
  8. ↑ Sefika M, Sane A, Campbell RH. "Monitoreo del cumplimiento 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-396.
  9. ↑ Budd T. "Introducción a la programación orientada a objetos". 3.ª ed. Addison Wesley; 2001.
  10. ↑ Page-Jones M. "Fundamentos del diseño orientado a objetos en UML". Addison-Wesley Professional; 1999.