Vad är en hjälpare? Är det ett designmönster? Är det en algoritm?

En hjälpklass är en mindre känd kodlukt där en kodare har identifierat olika, vanligt förekommande operationer och försökt göra dem återanvändbara genom att klumpa ihop dem tillsammans i en onaturlig gruppering. Efterföljande utvecklare har sedan kommit in i projektet och inte insett att hjälpklassen existerar och har följaktligen skrivit om samma vanliga operationer eller till och med skapat fler hjälpklasser.

Men på allvar är huvudproblemet med hjälpklasser att de vanligtvis är operationer som agerar på en specifik klass, vilket uppenbarligen betyder i OO-termer att de lider av ett akut fall av Feature Envy . Det här misslyckandet med att paketera beteendet med de data det agerar på är varför utvecklare så ofta (enligt min erfarenhet) inte hittar det.

Utöver detta, som du redan har identifierat SomethingSomethingHelper är faktiskt ett fruktansvärt namn . Det är obeskrivligt och ger dig ingen verklig insikt om vilken typ av operationer klassen gör (det hjälper?), Vilket också betyder att det inte är uppenbart när man lägger till nya beteenden om de hör hemma i Helper-klassen eller inte. Jag skulle bryta upp sådana klasser i linje med relaterat beteende som logiskt grupperas och sedan byta namn på de nya klasserna för att återspegla vad det gör.

Kommentarer

• Ganska se till att SomethingSomethingHelper inte är klassens faktiska namn. Om det ’ en kod luktar eller inte beror på hur specifikt hjälpklassen är, eftersom hjälpklasser som Math inte alls är en kodlukt.
• @RobertHarvey – Enh, de flesta av dem jag ’ har sett har fått namnet SomethingSomethingHelper. Helvete, jag ’ m tittar på en klass just nu med namnet HelperMethods i <company>.Helpers namnområdet. För mig är en -klassen finns i samma hink som *Manager.
• @Telastyn: Kanske är det ’ s en upplevelse sak, då. Jag ’ har tittat igenom hjälpklasserna i mitt nuvarande projekt (det finns flera), och de har alla betydelsefulla namn. Det finns ’ endast en som ’ är eftersläppt med Helper, och jag tror att ’ s för att skilja den från en klass i .NET Framework med samma namn. Jag ’ Jag anser att *Helper är acceptabelt om * var något meningsfullt. HelperMethods är bara ett fantasisvikt; det borde åtminstone finnas specifika konceptuella hinkar.
• @RobertHarvey – Du ’ har förmodligen rätt. Hela min karriär med moderna språk har jag rensat tågvrak.
• Det finns en delmängd av dessa, som heter ” hjälpfunktioner ”, det är faktiskt användbart och ett bra mönster.Till exempel, en vanlig uppsättning rader som annars skulle behöva upprepas inom en funktion – ett exempel på var de dyker upp är när du behöver en do..while slinga i Python, som språket stöder inte ’ (se det andra exemplet här ). En annan skulle vara en if / elif /…/ else-struktur, men måste upprepa ett fall längst upp och längst ner. Om möjligt bör de dock göras lokala för den funktionen, och vanligtvis inte kallas ” hjälpar ”.

En hjälpare är en ofarlig extra klass eller metod, så länge den kompletterar en extern komponent. När det gör det motsatta, indikerar det dålig design eftersom koden har uteslutits från dess myndighet, om det alls finns någon auktoritet.

Här är ett exempel på en ofarlig hjälpar, jag använder en metod som kallas FindRep som räknar antalet ledande nollor.

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

Hjälparmetoden är väldigt enkel, men mycket obekväm att kopiera och klistra in och ramverket ger ingen lösning.

 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; }  

Och här är ett exempel på en dålig hjälpare:

 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; } } }  

Kommentarer

• Så visa mig hur DutchZipcodeHelper ska göras?
• @ powder366 Validate is a private metod på DutchZipcode

Helper är ett vanligt namnnamn.

Men , det kommunicerar väldigt lite a om vad det gör. Varje gång jag har sett det använt har jag funnit att det är ett suboptimalt namn.

Jag anser faktiskt att det är en kodlukt som indikerar fler problem under.

Exempel

Antag att vi ser namnet ” WidgetHelper ” (här ” widget ” är ett stand-in-namn för alla typer av programmerbar funktion, och inte nödvändigtvis en UI-widget):

 class WidgetHelper: ...  

Vad lär vi oss av namnet? Vi vet att objektet eller funktionen utför någon form av arbete sekundärt till widgeten. Det är min erfarenhet att detta kanske inte ens är sant, och man kan ta bort ” hjälpar ” från namnet och förbättra kommunikationen.

För en annan möjlighet kan ” WidgetHelper ” omsluta widgeten, så att själva widgetkoden kanske vet ingenting om hjälparen. Implikationen är att WidgetHelper i detta pseudokodsexempel är en del av det offentliga API: et:

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

I det här fallet skulle något som ” WidgetAPI ” vara ett bättre namn, eftersom det åtminstone informerar användaren om dess relation till widgetklassen. Eller kanske tar vi bort ” Helper ” från namnet och byter namn på Widget till något som WidgetImplementation.

Alternativt kan den slås in och kallas av widgeten, vilket antyder att den inte är en del av det offentliga API: et, men snarare en del av implementeringsdetaljerna.

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

Även i det här fallet, med detta liten mängd information vi har en förbättring av ” hjälpar. ” Det skulle vara mer beskrivande att kalla det något generiskt namn som ” WidgetImplementation. ”

” Implementering ” kan vara korrekt eftersom implementeringen kan göra för mycket för att ge det ett mer exakt namn. Eller det kan i sig vara för vagt – detta bestäms av namnet.

Men som vi har sett, namnet ” hjälpar, ” hjälper inte till att förstå vad som händer i koden, förutom att det är ett underordnat huvudintresse. ” Helper, ” kan betyda många slags relationer. Det är alltså alltför vagt och otydligt och inte lämpligt för att informera användaren om vad objektet gör.

Slutsats

Namngivning av saker är ett av de hårda problemen inom datavetenskap.

Vad som är önskvärt i ett namn är att det informerar användaren om vad den nämnda saken ska göra.

Men i alla fall tänkbara skulle det vara mer beskrivande att använda ett annat namn än ” hjälpare ” eller helt enkelt ta bort den helt.

Som en följd av min erfarenhet och den här diskussionen signalerar valet av ” hjälpar ” i ett namn låg ansträngning eller sofistikering från namerns sida (korrekt eller inte). Det är i själva verket en kodlukt.

Vänligen kalla inte något ” hjälpare. ”

Det är faktiskt varken.

” Hjälpare ” är ett samlingsnamn för en grupp funktioner.

En hjälpare är något som fungerar över hela projektet och gör en liten sak. Dessa killar är ofta inte ens organiserade i en klass, de utökar bara funktionaliteten eller möjligheterna i själva språket. Här är vad jag anser vara ett mycket bra exempel på en hjälpare:

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

Denna lilla funktion kan ha stor inverkan på hur du organiserar din kod (du kommer gärna att lägga dina bokstavliga listor i flerlinjiga strängar) men i sig betyder det nästan ingenting. Det är ett förhärligt regexmönster. Ändå gör det din kod mycket läsbar när du säger

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

istället för dess rena regexekvivalent.

Så det är vad hjälpare är. Små verktyg för generiska jobb, som inte tillhör en viss klass. Du kan tvinga dem till en (linesOf kan vara en metod för en strängklass) men där de verkligen hör hemma är antingen det globala namnområdet eller en statisk samling av sådana verktyg.

Tummen regel: om det är till hjälp men inte verkar hör hemma någonstans, är det förmodligen en hjälpare.

Naturligtvis ” detta är ett grått område, ” men min pragmatiska erfarenhet har varit att människor uppfinner ” hjälpare ” när de har identifierat någon användbar uppsättning gemensam kod som de inte har ”t vill implementera om. (Vissa språk hänvisar till dessa som ” mixins. ”)

Problemet är att den gemensamma koden är tangentiellt relaterade till var och en av de andra klasserna som det kan ” hjälpa. ” I stället för att vara en del av en strikt klasshierarki, det hjälper bara ” till ” [alla …] dem. Denna strategi undviker duplicering av källkoden men den är inte utan dess faror.

Mitt företag använde tidigare basen klass / hjälpklassmetodik där varje objekt skulle ha två klasser. Du skulle ha en Person-klass som innehöll alla klassegenskaper och definitioner och en PersonHelper-klass som innehöll alla de metoder, SQL-uttalanden och logik som manipulerade Person-klassen. Detta fungerade bra för oss eftersom alla våra applikationer använder SQL-uttalanden för att manipulera data och det var väldigt enkelt för oss att hitta och ändra SQL-uttalanden efter behov.

Vi har sedan gått vidare och placerar nu allt i Person / Base-klassen. Vi slutade använda Helper-namngivningskonventionen eftersom vi ville ha färre filer i våra projekt. Längden på några av klassnamnen var också ur kontroll. LOL.

Inte ett bra exempel men du får idén.

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

Jag säger inte att det är perfekt att använda hjälpmedelsnamnkonventionen lösning men det fungerade för oss i några år.

Kommentarer

• Du gjorde inte ’ t förklara varför.
• Ja, jag ’ gillar den förklaringen också.
• @AaronHall Anser det som en bra sak som du inte förstår deras val.
• Den vanliga anledningen är ” Någon tyckte att det var en bra idé ”.