Designový zápach - Design smell

v programování, design voní jsou „struktury v designu, které naznačují porušení základních principů designu a negativně ovlivňují kvalitu designu“.[1] Původ výrazu „designový zápach“ lze vysledovat až k výrazu „kód vůně "který byl uveden v knize Refaktoring: Vylepšení designu stávajícího kódu podle Martin Fowler.[2]

Detaily

Různí autoři definovali slovo „vůně“ různými způsoby:

  • N. Moha et al.: „Vůně kódu a designu jsou špatným řešením opakujících se problémů s implementací a designem.“[3]
  • R. C. Martin: „Vůně designu jsou pachy tlejícího softwaru.“[4]
  • Fowler: „Vůně jsou určité struktury kódu, které naznačují (někdy křičí) možnost refaktorování.“[2]

Vůně designu naznačují nahromaděný dluh designu (jedna z významných dimenzí společnosti technický dluh ). Chyby nebo neimplementované funkce nejsou považovány za vůně designu. Vůně designu vznikají ze špatných rozhodnutí o designu, díky nimž je design křehký a obtížně udržovatelný. Osvědčeným postupem je identifikovat vůně designu v softwarovém systému a použít vhodné refaktorování k jeho eliminaci, aby se zabránilo hromadění technického dluhu.

Kontext (charakterizovaný různými faktory, jako je problém, designový ekosystém a platforma) hraje důležitou roli při rozhodování, zda určitá struktura nebo rozhodnutí by mělo být považováno za vůni designu. Obecně je vhodné žít s vůněmi designu kvůli omezením uloženým kontextem.

Společný design voní

  • Chybí abstrakce[1] když se místo vytváření abstrakce používají shluky dat nebo kódované řetězce. Také známý jako „primitivní posedlost“ [2] a „shluky dat“.[2]
  • Mnohostranná abstrakce[1] když má abstrakce přiděleno více odpovědností. Také známý jako „zneužití konceptualizace“.[5]
  • Duplicitní abstrakce[1] když dvě nebo více abstrakcí mají shodné názvy nebo implementaci nebo obojí. Také známý jako „alternativní třídy s různými rozhraními“[2] a „duplicitní návrhové artefakty“.[6]
  • Nedostatečné zapouzdření[1] když je deklarovaná přístupnost jednoho nebo více členů abstrakce tolerantnější, než je ve skutečnosti požadována.
  • Nevyužité zapouzdření[1] když klientský kód používá explicitní kontroly typu (pomocí zřetězených příkazů if-else nebo příkazů switch, které kontrolují typ objektu) namísto využití variace typů již zapouzdřených v hierarchii.
  • Nefunkční modularizace[1] když jsou data a / nebo metody, které by v ideálním případě měly být lokalizovány do jedné abstrakce, odděleny a rozloženy do více abstrakcí.
  • Nedostatečná modularizace[1] když existuje abstrakce, která nebyla zcela rozložena, a další rozklad by mohl snížit její velikost, složitost implementace nebo obojí.
  • Kruhová závislost. Cyklicky závislá modularizace [1] když dvě nebo více abstrakcí na sobě přímo nebo nepřímo závisí (vytvoření těsného spojení mezi abstrakcemi). Také se označuje jako „cyklické závislosti“.[7]. Cyklická hierarchie [1] když supertyp v hierarchii závisí na kterémkoli z jeho podtypů. Také známý jako „dědické / referenční cykly“.[8]
  • Nefaktorizovaná hierarchie[1] když je v hierarchii zbytečná duplikace mezi typy.
  • Poškozená hierarchie[1] když supertyp a jeho podtyp koncepčně nesdílejí vztah „IS-A“, což má za následek nefunkční zastupitelnost. Také známý jako „nevhodné využití dědictví“[9] a „nesprávné použití IS A“.[10]

Viz také

Reference

  1. ^ A b C d E F G h i j k l Girish Suryanarayana, Ganesh SG, Tushar Sharma (2014). Msgstr "Refaktoring vůně softwarového designu: Správa technického dluhu". Morgan Kaufmann. ISBN  978-0128013977
  2. ^ A b C d E Fowler, Martin (1999). Refaktorování. Vylepšení designu stávajícího kódu. Addison-Wesley. ISBN  0-201-48567-2.
  3. ^ N. Moha, Y. Gueheneuc, L. Duchien a A. Le Meur. "Decor: Metoda pro specifikaci a detekci zápachu kódu a designu". IEEE Trans. Softw. Eng., 36 (1): 20–36, leden 2010.
  4. ^ R. C. Martin. Agilní vývoj softwaru, principy, vzory a postupy. Addison-Wesley, 2003.
  5. ^ Trifu A. "Automatizovaná strategie založená na restrukturalizaci objektově orientovaného kódu". In Proceedings of the 7. German workshop on software-reengineering (WSR); 2005.
  6. ^ Stal M. „Refaktorování softwarové architektury“. Výukový program Mezinárodní konference o objektově orientovaném programování, systémech, jazycích a aplikacích (OOPSLA); 2007.
  7. ^ Page-Jones M. „Praktický průvodce návrhem strukturovaných systémů“. 2. vyd. Prentice Hall; 1988.
  8. ^ Sefika M, Sane A, Campbell RH. „Monitorování souladu softwarového systému s jeho designovými modely na vysoké úrovni“. Ve sborníku z 18. mezinárodní konference o softwarovém inženýrství, ICSE ‘96, Washington, DC; 1996. s. 387–96.
  9. ^ Budd T. „Úvod do objektově orientovaného programování“. 3. vyd. Addison Wesley; 2001.
  10. ^ Page-Jones M. „Základy objektově orientovaného designu v UML“. Addison-Wesley Professional; 1999.