Hva er en hjelper? Er det et designmønster? Er det en algoritme?

En hjelperklasse er en mindre kjent kodelukt der en koder har identifisert noen forskjellige, ofte brukte operasjoner og forsøkt å gjøre dem gjenbrukbare ved å klumpe dem sammen i en unaturlig gruppering. Suksessive utviklere har da kommet inn i prosjektet og ikke innsett at hjelperklassen eksisterer, og har derfor omskrevet de samme vanlige operasjonene, eller til og med opprettet flere hjelperklasser. at de vanligvis er operasjoner som virker på en bestemt klasse, noe som åpenbart betyr i OO-termer at de lider av et akutt tilfelle av Feature Envy . Denne unnlatelsen av å pakke oppførselen med dataene den handler på, er grunnen til at utviklere så ofte (etter min erfaring) ikke finner den.

I tillegg til dette, som du allerede har identifisert SomethingSomethingHelper er faktisk et forferdelig navn . Det er ikke beskrivende, og gir deg ingen reell anelse om hva slags operasjoner klassen gjør (det hjelper?), Noe som også betyr at det ikke er åpenbart når du legger til ny atferd om de hører hjemme i Helper-klassen eller ikke. Jeg ville knekke opp slike klasser i tråd med relatert oppførsel som logisk grupperer seg, og gi deretter nye navn til de nye klassene for å gjenspeile hva det gjør.

Kommentarer

• Pretty at SomethingSomethingHelper ikke er det faktiske navnet på klassen. Om det ‘ en kode lukter eller ikke, vil avhenge av hvor spesifikk hjelperklassen er, ettersom hjelperklasser som Math ikke er en kodelukt i det hele tatt.
• @RobertHarvey – Enh, de fleste av dem jeg ‘ har sett har fått navnet SomethingSomethingHelper. Helvete, jeg ‘ m ser på en klasse som nå heter HelperMethods i <company>.Helpers navneområdet. For meg er en -klassen er i samme bøtte som *Manager.
• @Telastyn: Kanskje det ‘ er en opplevelses ting, da. Jeg ‘ har sett gjennom hjelperklassene i mitt nåværende prosjekt (det er flere), og de har alle meningsfulle navn. Der er ‘ bare en som ‘ s er etterfulgt av Helper, og jeg tror at ‘ s for å gjøre den entydig fra en klasse i .NET Framework med samme navn. Jeg ‘ d anser *Helper akseptabelt hvis * var noe meningsfylt. HelperMethods er bare en fantasisvikt; det burde i det minste være spesifikke konseptuelle bøtter.
• @RobertHarvey – Du ‘ har sannsynligvis rett. Hele karrieren min ved å bruke moderne språk har vært å rydde opp i vraket.
• Det er en delmengde av disse, kalt » hjelperfunksjoner «, som faktisk er nyttige og et godt mønster.For eksempel er et vanlig sett med linjer som ellers må gjentas i en funksjon – et eksempel på hvor de dukker opp er når du trenger en do..while loop i Python, som språket støtter ikke ‘ t (se det andre eksemplet her ). En annen ville være en if / elif /…/ annet struktur, men må gjenta en sak øverst og nederst. Hvis det er mulig, bør de gjøres lokale for den funksjonen, men de kalles generelt ikke » hjelper «.

En hjelper er en ufarlig tilleggsklasse eller metode, så lenge den utfyller en ekstern komponent. Når det gjør det motsatte, indikerer det dårlig design fordi koden er ekskludert fra autoriteten, hvis det i det hele tatt er noen autoritet.

Her er et eksempel på en ufarlig hjelper, jeg bruker en metode som heter FindRep som teller antall ledende nuller.

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

Hjelpemetoden er veldig enkel, men veldig upraktisk å kopiere og lime rundt, og rammeverket gir 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; }  

Og her er et eksempel på en dårlig hjelper:

 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å vis meg hvordan DutchZipcodeHelper skal gjøres?
• @ powder366 Validate is a private metode på nederlandsk postnummer

Hjelper er et vanlig navnebilag.

Imidlertid , det kommuniserer veldig lite a om hva det gjør. Hver gang jeg har sett den brukt, har jeg funnet at den er et suboptimalt navn.

Faktisk anser jeg det for å være en kodelukt som indikerer flere problemer under.

Eksempel

Anta at vi ser navnet » WidgetHelper » (her » widget » er et stand-in-navn for alle slags programmerbare funksjoner, og ikke nødvendigvis en brukergrensesnitt-widget):

 class WidgetHelper: ...  

Hva lærer vi av navnet? Vi vet at objektet eller funksjonen gjør noe slags arbeid sekundært til widgeten. Det er min erfaring at dette ikke en gang kan være sant, og man kan slette » hjelper » fra navnet og forbedre kommunikasjonen.

For en annen mulighet, kan » WidgetHelper » pakke inn widgeten, slik at widgetkoden selv kan vite ingenting om hjelperen. Implikasjonen er at WidgetHelper i dette pseudokodeeksemplet er en del av det offentlige API: et:

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

I dette tilfellet ville noe som » WidgetAPI » være et bedre navn, fordi det i det minste informerer brukeren om forholdet til widget-klassen. Eller kanskje vi sletter » Hjelper » fra navnet og omdøper i tillegg Widget til noe sånt WidgetImplementation.

Alternativt kan den pakkes inn og kalles av widgeten, og antyder at den er ikke en del av det offentlige API-et, men heller en del av implementeringsdetaljene.

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

Selv i dette tilfellet, med dette liten mengde informasjon har vi en forbedring av » hjelper. » Det ville være mer beskrivende å kalle det et generisk navn som » WidgetImplementation. »

» Implementering » kan være riktig da implementeringen kan gjøre for mye for å gi det et mer presist navn. Eller det kan i seg selv være for vagt – dette er namerens skjønn.

Men som vi har sett, navnet » hjelper, » hjelper ikke til å forstå hva som skjer i koden, bortsett fra at den er tilknyttet hovedobjektet av interesse. » Hjelper, » kan bety mange slags forhold. Dermed er det altfor vag og tåkete, og ikke velegnet for formålet å informere brukeren hva objektet gjør.

Konklusjon

Å navngi ting er et av de vanskelige problemene innen informatikk.

Det som er ønskelig i et navn er at det informerer brukeren om hva den nevnte tingen skal gjøre.

Men uansett tenkelig, ville det være mer beskrivende å bruke et annet navn enn » hjelper » eller bare fjern den helt.

Som en følge av min erfaring og denne diskusjonen, signaliserer også valget av » hjelper » lav innsats eller sofistikering fra namerens side (riktig eller ikke). Det er faktisk en kodelukt.

Ikke kall noe » hjelper. »

Det er faktisk ingen av dem.

» Hjelper » er et samlet substantiv for en gruppe funksjoner.

En hjelper er noe som fungerer på tvers av prosjektet og gjør en liten ting. Disse karene er ofte ikke engang organisert i en klasse, de utvider bare funksjonaliteten eller mulighetene til selve språket. Her er det jeg anser som et veldig godt eksempel på en hjelper:

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

Denne lille funksjonen kan ha stor innvirkning på hvordan du organiserer koden din (du vil gjerne sette bokstavelige lister i flere linjer), men i seg selv betyr det nesten ingenting. Det er et glorifisert regex-mønster. Likevel gjør det koden din mye mer lesbar når du sier

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

i stedet for det rene regex-ekvivalenten.

Så det er hva hjelpere er. Små verktøy for generiske jobber, ikke tilhører en bestemt klasse. Du kan tvinge dem til en (linesOf kan være en metode for en strengklasse), men hvor de virkelig hører hjemme er enten det globale navneområdet eller en statisk samling av slike verktøy.

Tommelfingerregel: hvis det er nyttig, men ikke ser ut til å høre hjemme hvor som helst, er det sannsynligvis en hjelper.

Selvfølgelig » dette er et grått område, » men min pragmatiske erfaring har vært at folk finner på » hjelpere » når de har identifisert noen nyttige-for-dem-sett med vanlig kode som de ikke har «vil ikke implementere på nytt. (Noen språk refererer til disse som » mixins. «)

Problemet er at felleskoden er tangentalt relatert til hver av de andre klassene at det kan » hjelpe. » I stedet for å være en del av et strengt klassehierarki, bare » hjelper » [alle …] dem. Denne strategien unngår duplisering av kildekoden, men den er ikke uten farene.

Mitt firma brukte basen klasse / Hjelper klassemetodikk hvor hvert objekt ville ha to klasser. Du ville ha en Person-klasse som inneholdt alle klasseegenskapene og definisjonene, og en PersonHelper-klasse som inneholdt alle metodene, SQL-setningene og logikken som manipulerte Person-klassen. Dette fungerte bra for oss fordi alle applikasjonene våre bruker SQL-setninger for å manipulere data, og det var veldig enkelt for oss å finne og endre SQL-setningene etter behov.

Vi har siden gått videre og nå plassert alt i Person / Base-klassen. Vi sluttet å bruke Helper-navnekonvensjonen fordi vi ønsket å ha færre filer i prosjektene våre. Også lengden på noen av klassenavnene kom ut av kontroll. lol.

Ikke et godt eksempel, men du får ideen.

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

Jeg sier ikke at det å bruke hjelpernavngivningskonvensjonen er den perfekte løsning, men det fungerte for oss i noen år.

Kommentarer

• Du gjorde ikke ‘ t forklar hvorfor.
• Ja, jeg ‘ liker den forklaringen også.
• @AaronHall Anser det som en god ting du ikke forstår deres valg.
• Den vanlige grunnen er » Noen syntes det var en god ide «.