Co je pomocník? Je to designový vzor? Je to algoritmus?

Třída pomocníka je méně známá vůně kódu, kde kodér identifikoval některé různé, běžně používané operace a pokusil se je znovu použít jejich soustředěním společně v nepřirozeném seskupení. Postupní vývojáři poté přišli na projekt a neuvědomili si, že třída pomocníka existuje, a následně přepsali stejné běžné operace nebo dokonce vytvořili více tříd pomocníků.

Ale vážně, hlavním problémem tříd pomocníků je že se obvykle jedná o operace, které působí na konkrétní třídu, což z hlediska OO zjevně znamená, že trpí akutním případem Feature Envy . Toto selhání při balení chování s daty, na která působí, je důvodem, proč ho vývojáři tak často (podle mých zkušeností) nenajdou.

Kromě toho, jak jste již identifikovali, je něco skutečně strašného . Je nepopsatelný a nedává vám žádné skutečné představy o tom, jaký druh operací třída dělá (pomáhá?), Což také znamená, že při přidávání nového chování není zřejmé, zda do třídy Helper patří nebo ne. Přerušil bych připravit takové třídy v duchu souvisejícího chování, které se logicky seskupují, a poté přejmenovat nové třídy tak, aby odrážely to, co dělá.

Komentáře

• hezké ujistěte se, že SomethingSomethingHelper není skutečný název třídy. Zda ‚ sa kód voní nebo ne, by záleželo na tom, jak konkrétní pomocná třída je, protože pomocné třídy jako Math vůbec nejsou vůní kódu.
• @RobertHarvey – Enh, většina z těch, které ‚ Viděl jsem byl pojmenován SomethingSomethingHelper. Sakra, já ‚ m při pohledu na třídu právě pojmenovanou HelperMethods ve <company>.Helpers oboru názvů. Pro mě je je ve stejném segmentu jako *Manager.
• @Telastyn: Možná ‚ Je to tedy zážitková věc. ‚ jsem prohlédl pomocné třídy v mém aktuálním projektu (je jich několik) a všechny mají smysluplná jména. Existuje ‚ pouze jeden, který ‚ s má příponu Helper a myslím, že ‚ s k disambiguaci od třídy v .NET Framework se stejným názvem. Považuji ‚ za *Helper přijatelné, pokud * bylo něco smysluplného. HelperMethods je jen selhání představivosti; měly by existovat alespoň konkrétní koncepční segmenty.
• @RobertHarvey – máte ‚ pravděpodobně pravdu. Celá moje kariéra v moderních jazycích čistila vraky vlaků.
• Existuje jejich podmnožina, která se nazývá “ pomocné funkce „, které jsou skutečně užitečné a mají dobrý vzor.Například běžná sada řádků, které by se jinak musely ve funkci opakovat – jedním příkladem, kde se zobrazují, je situace, kdy potřebujete smyčku do..while v Pythonu, kterou jazyk nepodporuje ‚ t (viz druhý příklad zde ). Další by byla struktura if / elif /…/ else, ale je třeba opakovat případ v horní a dolní části. Pokud je to možné, měly by být pro tuto funkci vytvořeny lokálně a obecně by se neměly nazývat “ pomocník „.

Pomocník je neškodná další třída nebo metoda, pokud doplňuje externí komponentu. Když to udělá naopak, pak to naznačuje špatný design, protože kód byl vyloučen z jeho oprávnění, pokud vůbec nějaké oprávnění existuje.

Zde je příklad neškodného pomocníka, používám metodu nazvanou FindRep který počítá počet úvodních nul.

 digits = digits.Remove(0, TextHelper.FindRep("0", digits, 0, digits.Length - 2));  

Pomocná metoda je velmi jednoduchá, ale velmi nepohodlná pro kopírování a vkládání a rámec neposkytuje žádné řešení.

 public static int FindRep(char chr, string str, int beginPos, int endPos) { int pos; for (pos = beginPos; pos <= endPos; pos++) { if (str[pos] != chr) { break; } } return pos - beginPos; }  

A tady je příklad špatného pomocníka:

 public static class DutchZipcodeHelper { public static bool Validate(string s) { return Regex.IsMatch(s, @"^[1-9][0-9]{3}[A-Z]{2}$", RegexOptions.IgnoreCase); } } public class DutchZipcode { private string value; public DutchZipcode(string value) { if (!DutchZipcodeHelper.Validate(value)) { throw new ArgumentException(); } this.value = value; } public string Value { get { return value; } } }  

Komentáře

• Ukaž mi tedy, jak by měl být DutchZipcodeHelper proveden?
• @ powder366 Ověřit je soukromý metoda na DutchZipcode

Pomocník je běžně používaný přídavný název.

Nicméně , komunikuje velmi málo co to dělá. Pokaždé, když jsem viděl, že se používá, zjistil jsem, že je to neoptimální název.

Ve skutečnosti to považuji za vůni kódu, která naznačuje další problémy pod ním.

Příklad

Předpokládejme, že vidíme název “ WidgetHelper “ (zde “ widget “ je náhradní název pro jakýkoli druh programovatelných funkcí, a nemusí to být nutně widget uživatelského rozhraní):

 class WidgetHelper: ...  

Co se z názvu dozvídáme? Víme, že objekt nebo funkce provádí nějakou práci sekundárně k widgetu. Mám zkušenost, že to nemusí být ve skutečnosti pravda, a dalo by se odstranit “ pomocníka “ z názvu a vylepšit komunikaci.

Pro další možnost může “ WidgetHelper “ zabalit widget tak, aby jej mohl znát samotný kód widgetu nic o pomocníkovi. Důsledkem je, že WidgetHelper v tomto příkladu pseudokódu je součástí veřejného API:

 class WidgetHelper: def __init__(self): self.widget = Widget() ...  

V tomto případě by něco jako “ WidgetAPI “ bylo lepší jméno, protože to alespoň informuje uživatele o jeho vztahu ke třídě Widget. Nebo možná odstraníme “ Helper “ z názvu a navíc přejmenujeme Widget na něco podobného WidgetImplementation.

Alternativně může být zabalen a volán widgetem, což znamená, že není součástí veřejného API, ale spíše součást podrobností implementace.

 class Widget: def __init__(self): self.widget_helper = WidgetHelper() ...  

I v tomto případě s tímto malé množství informací máme vylepšení “ pomocníka. “ Bylo by popisnější nazývat to obecným názvem jako “ WidgetImplementation. “

“ Implementace “ může být správný, protože implementace může udělat příliš mnoho, aby dala přesnější název. Nebo to může být samo o sobě příliš vágní – je to na uvážení jmenovatele.

Ale jak jsme viděli, jméno, “ pomocník, “ nepomůže pochopit, co se v kódu děje, kromě toho, že je doplňkem hlavního předmětu zájmu. “ Pomocník, “ může znamenat mnoho druhů vztahů. Je tedy příliš vágní a mlhavý a není vhodný pro informování uživatele o tom, co objekt dělá.

Závěr

Pojmenování věcí je jedním z těžkých problémů počítačové vědy.

Co je žádoucí v názvu, je informovat uživatele, co má pojmenovaná věc dělat.

V každém případě si lze představit, že by bylo popisnější použít jiný název než “ helper “ nebo jednoduše úplně odstranit.

Jako důsledek mé zkušenosti a této diskuse také volba “ pomocníka “ signalizuje malé úsilí nebo sofistikovanost ze strany namer (správně nebo ne). Je to opravdu vůně kódu.

Prosím, neříkejte nic “ pomocníkem. “

Ve skutečnosti ani jedna.

“ Pomocník “ je souhrnné podstatné jméno pro skupinu funkcí.

Pomocník je něco, co funguje napříč projektem a dělá malou věc. Tito muži často nejsou ani organizovaní do třídy, pouze rozšiřují funkčnost nebo možnosti samotného jazyka. Zde považuji za velmi dobrý příklad pomocníka:

 function linesOf($mls) { return preg_split("/\s*\n\s*/",trim($mls)); }  

Tato drobná funkce může mít velký dopad na to, jak organizujete svůj kód (budete rádi, když své doslovné seznamy umístíte do víceřádkových řetězců), ale sama o sobě znamená téměř nic. Je to oslavovaný vzor regulárního výrazu. Přesto bude váš kód mnohem čitelnější, když řeknete

 $a = linesOf(" apples bananas cherries ");  

místo čistého ekvivalentu regulárního výrazu.

Takže právě takoví pomocníci jsou. Drobné nástroje pro obecné úlohy, které nepatří do konkrétní třídy. Můžete je vynutit do jednoho (linesOf může být metodou třídy řetězců), ale tam, kam skutečně patří, je buď globální obor jmen, nebo jedna statická sbírka takových nástrojů.

Palecové pravidlo: pokud je užitečné, ale zdá se, že nepatří nikam, je pravděpodobně pomocníkem.

Samozřejmě “ toto je šedá oblast, “ ale moje pragmatická zkušenost byla, že lidé vymýšlejí “ pomocníky „, když identifikují nějakou užitečnou sadu běžného kódu, který jim „Nechci to znovu implementovat. (Některé jazyky je označují jako “ mixiny. „)

Problém je v tom, že běžný kód je tečně souvisí s každou z ostatních tříd, což by “ mohlo pomoci. “ Místo toho, aby byla nějakou součástí přísná hierarchie tříd, pouze “ pomáhá jim “ [všem …]. Tato strategie se vyhne duplikaci zdrojového kódu, ale není bez nebezpečí.

Moje společnost používala Base třída / metodika třídy Pomocník, kde by každý objekt měl dvě třídy. Měli byste Person třídu, která obsahovala všechny vlastnosti a definice třídy a PersonHelper třídu, která obsahovala všechny metody, příkazy SQL a Logic, které manipulovaly Person třídu. To pro nás fungovalo dobře, protože všechny naše aplikace používají příkazy SQL k manipulaci s daty a bylo pro nás velmi snadné najít a upravit příkazy SQL podle potřeby.

Od té doby jsme se přesunuli a nyní jsme vše zařadili do třídy Person / Base. Přestali jsme používat konvenci pojmenování Helper, protože jsme chtěli mít v našich projektech méně souborů. Délka některých názvů tříd se také vymkla kontrole. lol.

Není to skvělý příklad, ale máte představu.

s = CompanyName.PersonHelper.GetPerson() s = CompanyName.Person.GetPerson() 

Neříkám, že použití konvence pojmenování pomocníka je perfektní řešení, ale fungovalo to pro nás několik let.

Komentáře

• Ne ‚ t vysvětlete proč.
• Ano, ‚ se mi toto vysvětlení také líbí.
• @AaronHall Považujte to za dobrou věc, které nerozumíte jejich volba.
• Obvyklým důvodem je “ Někdo si myslel, že to byl dobrý nápad „.