it-swarm-eu.dev

Kdy mám použít - a ne použít - návrhové vzory?

V předchozí otázka mého na Stack Overflow , FredOverflow zmíněných v komentářích:

Upozorňujeme, že vzory magicky nezlepšují kvalitu kódu.

a

Jakékoli měřítko kvality, jaké si dokážete představit. Vzory nejsou všelék. Jednou jsem napsal hru Tetris s asi 100 třídami, které zahrnovaly všechny vzorce, které jsem tehdy znal. Proč používat jednoduchý if/else, pokud můžete použít vzor? OO je dobrý a vzorce jsou ještě lepší, že? Ne, byl to hrozný, přepracovaný kus svinstva.

Těmito poznámkami jsem docela zmatený: Vím, že návrhové vzory pomáhají zajistit, aby byl kód znovu použitelný a čitelný, ale kdy bych měl používat návrhové vzory a možná ještě důležitější je, kdy bych se měl vyhnout tomu, abych je s nimi unesl?

57
ashmish2

POLIBEK nejprve, vzory později, možná mnohem později. Vzor je většinou stav mysli. Nikdy se nepokoušejte donutit váš kód do konkrétního vzoru, spíše si všimněte, které vzory začínají krystalizovat z vašeho kódu a trochu jim pomohou.

Rozhodnutí "ok, budu psát program, který X používá vzor Y", je recept na katastrofu. Mohlo by to fungovat pro programy světové třídy vhodné pro demonstraci kódových konstrukcí pro vzory, ale ne mnohem víc.

99
jwenting

Myslím, že hlavním problémem je, že lidé mají často tendenci zneužívat vzory designu. Naučí se jich několik, vidí jejich užitečnost a aniž by si to uvědomili, proměnili těch pár vzorů v jakési zlaté kladivo, které pak aplikují na všechno.

Klíčem není nutně naučit se vzory samy. Klíčem je naučit se identifikovat scénáře a problémy, které mají vzory řešit. Pak je použití vzoru jednoduše otázkou použití správného nástroje pro danou úlohu. Je to úkol, který musí být identifikován a pochopen, než bude možné nástroj vybrat.

A někdy je to zvláštní nastavení a neexistuje žádný vzorec, který by jej vyřešil hned po vybalení z krabice. V tomto okamžiku je třeba věnovat větší pozornost problému než řešení. Rozdělte jej na problémy s komponentami, identifikujte oblasti problému, které sdílejí společné rysy s problémy řešenými známými vzory, upravte vzory tak, aby vyhovovaly problému atd.

52
David

Designový vzor funguje nejlépe, když je ve vašem týmu používán jako běžný jazyk .

Tím myslím, že můžete říct něco jako "tato třída je Singleton , která implementuje náš IHairyWidget Abstraktní továrna " a všichni ve vašem týmu rozumí tomu, co to znamená, aniž by museli jít do podrobných vysvětlení.

Tam, kde Design Patterns selžou, je to, když jim tým nerozumí, nebo když jsou tak nadměrně využívány, že přestanou dělat přehlednější design a místo toho ztěžují porozumět tomu, co se ve skutečnosti děje.

24
GrahamS

možná trochu mimo téma, ale myslím, že se to týká i vaší otázky: Navrhl bych vám dobrou knihu Refactoring to Patterns :

Tato kniha představuje teorii a praxi refaktorů zaměřených na vzor: sekvence nízkoúrovňových refaktorů, které umožňují návrhářům bezpečně přesouvat návrhy k implementacím vzorů, k nim nebo od nich . Kerievsky pomocí kódu z projektů v reálném světě dokumentuje myšlení a kroky, které jsou základem dvou desítek návrhových transformací založených na vzorech. Po cestě nabízí pohled na rozdíly vzorů a jak implementovat vzory nejjednodušším možným způsobem.

najdete příklady, kdy je možné použít návrhové vzory, a také když je musíte od nich odejít, abyste nekomplikovali aplikaci. A ano, hlavní myšlenkou je udržet vše co nejjednodušší.

Dobrá odpověď/rada na vaši otázku byla v článku Rozpoznáváte 4 včasné varovné signály zneužívání vzorů? , ale nemohu ji načíst hned, chyba 500. Není velká, takže jsem právě to používá Google cache:

Vzory návrhů softwaru mohou a mohou vést k přepracování

Přepracování je proces, který něco komplikuje. V případě programování, aby váš kód složitější a možná flexibilnější, než to musí být. Přesněji řečeno, implementace komplexních návrhů softwarových návrhů na jednoduché problémy.

1. Začněte jednoduše, není složité

Jak se to stane? Obvykle programujete v extra funkcích, o kterých se domníváte, že budou později použity. Co se však stane, když se to nikdy nestane? Ve většině případů tam zanechá křidélka. To se neodstraní. Softwarový systém tak neustále roste ve velikosti a složitosti se všemi těmito funkcemi, které se nikdy nepoužívají.

2. Dávejte pozor na příznaky

To je asi pro každého jiné, ale ve většině případů mám podezření, že to není vědomé úsilí. Ale spíše je to něco vyvolané strachem z toho, že uvízl s nepříjemným, nezpůsobilým, nevhodným nebo jednoduše řečeným špatným designem; být zaseknutý něčím, co prostě není dostatečně flexibilní. Je ironií, že pokud se dostanete do bodu nad strojírenstvím nebo nad aplikací vzorů, jste na správném místě, kde jste začali.

Vzory softwarového designu přitahují programátory nebo vývojáře, protože jim umožňují přirozeně vyjadřovat a vytvářet krásné architektury. Je to součást zábavného tvůrčího programování.

3. Zvažte přeorientování podle vzoru, spíše než od jednoho

Jaký může být dobrý způsob, jak se tomuto zneužití vzorových vzorů vyhnout? Zvažte přeorientování podle vzoru, spíše než začátek od jednoho. Nezkoušejte donutit vzor do svého návrhu. Šance jsou, že váš návrh by mohl být mnohem jednodušší bez něj. Pokud v pozdějším stádiu zjistíte, že by váš návrh mohl skutečně těžit ze strukturovaného vzoru, pak by to měl reflektor umožnit. Když navrhujete, vyřešte problém nejjednodušším možným způsobem. Jednoduchý software s nízkou hmotností je vždy dobrá věc. Existují lepší způsoby, jak se vyvarovat alternativy, která není dostatečně vyvinutá, pokud vás uvízne design nebo řešení, které prostě není dostatečně flexibilní nebo nevyhovuje problému.

4. Nenuťte se, abyste si to udělali poprvé

Vynucení vzorů nebo struktur softwarového designu do designu prostě není odpověď, to je jen špatný design. Prototypování nebo vytváření počátečního sestavení0 (důkaz vytvoření konceptu před zahájením výroby na skutečném produktu) však může tomuto problému a problému nadměrného inženýrství zabránit. Protože se necítíte, jako byste to měli udělat poprvé správně.

Původní URL (nyní mrtvá): http://codelines.net.au/article/do-you-recognise-the-4-early-warning-signs-of-design-pattern-abuse/

14
Maxym

kdy přestat dělat všechno pomocí vzorů?

Otázka je, kdy jste začali dělat všechno pomocí vzorů? Ne všechna řešení úhledně zapadají do existujícího vzoru designu a přijetí vzoru může znamenat, že zabalíte čistotu vašeho řešení. Možná zjistíte, že spíše než návrhový vzorec, který řeší váš problém, vytvoříte další problém tím, že se pokusíte donutit své řešení , aby vyhovovalo vzorovému vzoru.

Samozřejmě, pokud zvolíte správný návrhový vzor pro konkrétní scénář, nebudete mít problém, výběr správného se však snadněji říká, než udělá.

Viděl jsem nadměrné používání vzorů v projektech, kde to opravdu není nutné.

Myslím, že klíč je - Pokuste se udržet váš kód čistý, modulární a čitelný a ujistěte se, že vaše třídy nejsou pevně spojené =. Nakonec můžete vidět, že jste neúmyslně použili variaci na standardní návrhový vzor. Možná byste si to uvědomili na samém začátku projektu, než začnete kódovat. Pokud kódujete jako většina lidí, které znám (včetně sebe), pak pravděpodobně ne :)

9
El Ronnoco

Nejdůležitější věcí je znát problém, který řešíte. Než se rozhodnete, zda vám zavedení nějakého vzoru přinese nějaké výhody oproti jeho nepoužívání (zvýšení výkonu, jednoduchost nebo cokoli). Související otázky: https://stackoverflow.com/questions/85272/how-do-you-know-when-to-use-design-patterns

5
sinek

Ne. návrhových vzorů zmíněných v původním/de-facto go-to textu na toto téma, tj. GoF vyžaduje docela trochu zkušeností a často několik opakování, a mozek-bouře s kompetentními kolegy, aby zvládli. Po této fázi, vzhledem k problému, vzhledem k architektuře, často nejpřirozenější návrhové vzory vycházejí docela zřejmým způsobem. Jakýkoli pokus donutit přizpůsobit designový vzor k problémům nebo zmapovat problémy s návrhovým vzorem je však nebezpečný. V takovém případě je nejlepší konzultovat odborníky, trochu zaútočit na mozek a vzít jej jako zážitek z učení. Pokud nejste docela spokojeni s běžně používanými 10-lichými designovými vzory, zůstane to trochu složitější a AFAIK, neexistují žádné zkratky.

Narazil jsem na milion projektů projektu SLOC C++ s množstvím příkladů vzorů přizpůsobených silou, takže chyby s.a. nadužívání není příliš neobvyklé.

4
icarus74

Takto to vypadá s jakýmkoli tématem, které vyžaduje, abyste se učili a uplatňovali pravidla :

  1. Pokud jste nováček, musíte dodržovat pravidla, protože nevíte lépe.
  2. Pokud jste amatér, sledujete role, protože víte, proč je potřebujete.
  3. Pokud jste profesionál, pracujete spíše s pravidly než proti nim, dobře víte, co použít, kde a kdy se nevztahují.
  4. Pokud jste odborník, ignorujete pravidla.
  5. Pokud jste zvládli své umění, dáváte přednost pravidlům, protože váš kód musí vidět i kategorie 1-3 lidí. :)

Totéž platí pro bojová umění, malování, psaní, fotbal, mechaniku, závodění atd. ...

Jako chlápek č. 5 obvykle učíte chlápky č. 1 až 4, jak se stát špičkou, takže vždy platí, a to i v konkurenčních kontextech.

( Jak překonat a ignorovat pravidla to vysvětluje v obecném smyslu, ale pravděpodobně existují lepší eseje.)

4
Macke

Pravidlo je, že neexistuje žádné pravidlo. Vaše zkušenost (úspěch více než selhání) vám řekne, kdy je použít čistě, kdy je přizpůsobit nebo kdy je vůbec nepoužívat.

Je zde prezentace od Dan Northa, ve kterém mluví trochu o učení a vzorcích

3
Augusto

Udržujte vše co nejjednodušší. Musím však vyřešit problém, možná budete chtít použít designový vzor, ​​spíše než znovuobjevovat kolo, protože mnoho návrhových vzorů poskytuje řešení běžných problémů. Ale jak jsem řekl: používejte je pouze tehdy, když to opravdu potřebujete.

2
Puce

Možná použijte vzorec KISS DRY SoC (ano, možná to není vzor, ​​ale zní to zábavně).

Nech to být jednoduché, hloupé.
Neopakujte se.
Rozdělení obav.

Myslím, že tyto tři body by měly být inspirativní pro každého programátora.

2
Fredrik Norlin

Problém s „vzory“ je v tom, že cokoli lze považovat za vzor a často je.

Dlouho jsem profesionálně vyvíjel kód, než jsem poprvé slyšel, jak někdo mluví o „vzorcích“, a po všechny ty roky se mi povedlo dobře. Ve skutečnosti, když se ohlédnu zpět, hodně věcí, které jsem napsal, vlastně následovalo některé dobře známé vzorce, alespoň do určité míry.

Mám na mysli, že striktně sledovat jakýkoli daný vzorec není ve skutečnosti odpověď. Dozvíte se o nových vzorcích, ale nenechte se s nimi svázaný: změní se. Osvědčená praxe kódování dnes není stejná jako osvědčená praxe kódování před deseti lety, a bez ohledu na to, jak jsou dnešní programátoři chytrí, můžete si být jisti, že o deset let do budoucnosti budou věci, které jsou dnes považovány za osvědčené postupy, supercedovány.

Off topic: V osobní poznámce opravdu nenávidím použití slovních vzorců v tomto kontextu. Pleská to zbytečného žargonu.

1
Spudley

Designové vzory se obvykle používají k vysvětlení širšího publika, co váš kód skutečně dělá. Tímto způsobem se lidem usnadní pochopení toho, co děláte. Jeden zřídka používá to jako odkaz přijít s řešeními, zatímco vzor může být ve skutečnosti implementován mnoha způsoby.

0
Gaurav Sehgal

Způsob, jakým strukturujete logiku kódu, by měl umožnit nováčkovi, aby jej mohl interpretovat a modifikovat. Mít vzor jen proto, že je to nejlepší praxe, nikam vás nedostane, pokud plně nerozumíte kontextu, jak, kdo a kde je tento kód a jak by mohl být použit.

Vzor „Keep it simple“ je spíše zdravým rozumem než vzorem a při vytváření kódu musí být součástí procesu myšlení vývojáře. Předpokládat, že každý dostane určitý vzorec, není nutně také správné. V ideálním případě chcete vzor, ​​který lze přečíst a identifikovat, aniž byste toho tolik věděli.

0
Oscar Villarreal

Imho to prostě znáš. Myslím, že jsem dokonce použil návrhový vzor, ​​než jsem poznal definici návrhového vzoru. Je to jen dobré kódování. Někdy to dokážete rozpoznat při psaní požadavků projektu a někdy musíte změnit svůj kód.

jwenting řekl KISS nejprve, vzory později . Myslím, že vzory jsou způsob, jak [~ # ~] líbat [~ # ~] projekt, protože můžete použít něco, o čem víte, že to funguje a ušetříte svůj čas v budoucnosti.

Jediná věc, která by se mohla pokazit, je to, že existuje mnoho způsobů, jak implementovat jediný vzorec vzoru, dokonce ve stejném jazyce, takže musíte úplně pochopit, jaký je váš problém.

0
dierre