Hvad er en hjælper? Er det et designmønster? Er det en algoritme?

En hjælperklasse er en mindre kendt kodelugt, hvor en koder har identificeret nogle forskellige, ofte anvendte operationer og forsøgt at gøre dem genanvendelige ved at klumpe dem sammen i en unaturlig gruppering. Efterfølgende udviklere er så kommet ind på projektet og har ikke forstået, at hjælperklassen eksisterer, og har derfor omskrevet de samme almindelige operationer eller endda oprettet flere hjælperklasser.

Men seriøst er hovedproblemet med hjælperklasser at de normalt er operationer, der virker på en bestemt klasse, hvilket naturligvis betyder i OO-termer, at de lider af et akut tilfælde af Feature Envy . Denne undladelse af at pakke adfærd med de data, den handler på, er grunden til, at udviklere så ofte (efter min erfaring) ikke finder den.

Ud over dette er som du allerede har identificeret SomethingSomethingHelper faktisk et forfærdeligt navn . Det er ikke-beskrivende og giver dig ingen reel forståelse af, hvilken slags operationer klassen gør (det hjælper?), Hvilket også betyder, at det ikke er indlysende, når du tilføjer ny adfærd, om de hører til Helper-klassen eller ej. op sådanne klasser i retning af relateret adfærd, der logisk grupperes sammen, og omdøb derefter de nye klasser for at afspejle, hvad det gør.

Kommentarer

• Pretty sikker på, at SomethingSomethingHelper ikke er det egentlige navn på klassen. Om det ‘ en kode lugter eller ikke, afhænger af, hvordan specifikt hjælperklassen er, da hjælperklasser som Math slet ikke er en kodelugt.
• @RobertHarvey – Enh, de fleste af dem jeg ‘ har set er blevet navngivet SomethingSomethingHelper. Helvede, jeg ‘ m ser på en klasse lige nu med navnet HelperMethods i <company>.Helpers navneområdet. For mig er en klasse er i samme spand som *Manager.
• @Telastyn: Måske er det ‘ så er det en oplevelses ting. Jeg ‘ har gennemgået hjælperklasserne i mit nuværende projekt (der er flere), og de har alle meningsfulde navne. Der er ‘ kun en, der ‘ er efterfulgt af Helper, og jeg tror, at ‘ s for at skelne mellem den fra en klasse i .NET Framework med samme navn. Jeg ‘ Jeg anser *Helper acceptabelt, hvis * var noget meningsfuldt. HelperMethods er bare en manglende fantasi; der burde i det mindste være specifikke konceptuelle spande.
• @RobertHarvey – Du ‘ har sandsynligvis ret. Hele min karriere ved hjælp af moderne sprog har været at rydde togvrag op.
• Der er en delmængde af disse kaldet ” hjælperfunktioner “, der faktisk er nyttige og et godt mønster.For eksempel er et fælles sæt linjer, der ellers skulle gentages inden for en funktion – et eksempel på, hvor de vises, er når du har brug for en do..while loop i Python, som sproget understøtter ikke ‘ (se det andet eksempel her ). En anden ville være en if / elif /…/ else-struktur, men skal gentage en sag øverst og nederst. Hvis det er muligt, skal de dog gøres lokale for denne funktion og generelt ikke kaldes ” hjælper “.

En hjælper er en harmløs ekstra klasse eller metode, så længe den supplerer en ekstern komponent. Når det gør det modsatte, indikerer det dårlig design, fordi koden er blevet udelukket fra dens autoritet, hvis der overhovedet er nogen autoritet.

Her er et eksempel på en harmløs hjælper, jeg bruger en metode kaldet FindRep der tæller antallet af førende nuller.

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

Hjælpemetoden er meget enkel, men meget ubelejlig at kopiere og indsætte, og rammen giver 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 hjælper:

 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 mig hvordan DutchZipcodeHelper skal gøres?
• @ powder366 Validate is a private metode på hollandsk postnummer

Hjælper er et almindeligt anvendt navnebilæg.

Dog , det kommunikerer meget lidt a om hvad det gør. Hver gang jeg har set det brugt, har jeg fundet det at være et suboptimalt navn.

Faktisk anser jeg det for at være en kodelugt, der indikerer flere problemer nedenunder.

Eksempel

Antag, at vi ser navnet ” WidgetHelper ” (her ” widget ” er et stand-in-navn til enhver form for programmerbar funktionalitet og ikke nødvendigvis en UI-widget):

 class WidgetHelper: ...  

Hvad lærer vi af navnet? Vi ved, at objektet eller funktionen udfører en slags arbejde sekundært til widgeten. Det er min erfaring, at dette måske ikke engang faktisk er sandt, og man kan slette ” hjælper ” fra navnet og forbedre kommunikationen.

For en anden mulighed kunne ” WidgetHelper ” pakke widgeten, så selve widgetkoden muligvis kender intet om hjælperen. Implikationen er, at WidgetHelper i dette pseudokodeeksempel er en del af det offentlige API:

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

I dette tilfælde ville noget som ” WidgetAPI ” være et bedre navn, fordi det i det mindste informerer brugeren om hans forhold til Widget-klassen. Eller måske sletter vi ” Hjælper ” fra navnet og omdøber desuden Widget til noget lignende WidgetImplementation.

Alternativt kan den pakkes ind og kaldes af widgeten, hvilket antyder, at den er ikke en del af den offentlige API, men snarere en del af implementeringsoplysningerne.

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

Selv i dette tilfælde med dette lille mængde information har vi en forbedring af ” hjælper. ” Det ville være mere beskrivende at kalde det et generisk navn som ” WidgetImplementation. ”

” Implementering ” kan være korrekt, da implementeringen kan gøre for meget for at give det et mere præcist navn. Eller det kan i sig selv være for vagt – det er namerens skøn.

Men som vi har set, navnet, ” hjælper, ” hjælper ikke med at forstå, hvad der foregår i koden, bortset fra at det er underordnet det vigtigste objekt af interesse. ” Hjælper, ” kan betyde mange slags forhold. Det er således alt for vagt og tåget og ikke velegnet til formålet at informere brugeren om, hvad objektet gør.

Konklusion

At navngive ting er et af de hårde problemer inden for datalogi.

Hvad der er ønskeligt i et navn er, at det informerer brugeren om, hvad den nævnte ting skal gøre.

Men under alle omstændigheder tænkelige ville det være mere beskrivende at bruge et andet navn end ” hjælper ” eller simpelthen fjern det helt.

Som et resultat af min erfaring og denne diskussion signaliserer også valget af ” hjælper ” i et navn lav indsats eller sofistikering fra navnerens side (korrekt eller ej). Det er faktisk en kodelugt.

Du må ikke kalde noget en ” hjælper. ”

Det er faktisk heller ikke.

” Hjælper ” er et samlet substantiv for en gruppe funktioner.

En hjælper er noget, der fungerer på tværs af projektet og gør en lille ting. Disse fyre er ofte ikke engang organiseret i en klasse, de udvider blot funktionaliteten eller kapaciteterne i selve sproget. Her er hvad jeg betragter som et meget godt eksempel på en hjælper:

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

Denne lille funktion kan have stor indflydelse på, hvordan du organiserer din kode (du vil elske at sætte dine bogstavelige lister i multiline strenge), men i sig selv betyder det næsten ingenting. Det er et herliggjort regex-mønster. Alligevel gør det din kode meget mere læselig, når du siger

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

i stedet for dets rene regex-ækvivalent.

Så det er, hvad hjælpere er. Lille værktøjer til generiske job, der ikke tilhører en bestemt klasse. Du kan tvinge dem til en (linesOf kan være en metode i en strengklasse), men hvor de virkelig hører hjemme er enten det globale navneområde eller en statisk samling af sådanne værktøjer.

Tommelfingerregel: hvis det er nyttigt, men ikke synes at høre hjemme hvor som helst, er det sandsynligvis en hjælper.

Selvfølgelig ” dette er et gråt område, ” men min pragmatiske oplevelse har været, at folk opfinder ” hjælpere “, når de har identificeret noget nyttigt-til-dem sæt fælles kode, som de ikke har “vil ikke implementere igen. (Nogle sprog henviser til disse som ” mixins. “)

Problemet er, at den fælles kode er tangentalt relateret til hver af de andre klasser, som det måske ” hjælper. ” I stedet for at være en del af et strengt klassehierarki, det hjælper kun ” til ” [alle …] dem. Denne strategi undgår duplikering af kildekoden, men den er ikke uden dens farer.

Min virksomhed brugte basen klasse / hjælper klassemetode, hvor hvert objekt ville have to klasser. Du ville have en Person-klasse, der indeholdt alle klasseegenskaber og definitioner, og en PersonHelper-klasse, der indeholdt alle de metoder, SQL-udsagn og logik, der manipulerede Person-klassen. Dette fungerede godt for os, fordi alle vores applikationer bruger SQL-udsagn til at manipulere data, og det var meget let for os at finde og ændre SQL-udsagnene efter behov.

Vi er siden gået videre og placerer nu alt i klassen Person / Base. Vi holdt op med at bruge Helper-navngivningskonventionen, fordi vi ønskede at have færre filer i vores projekter. Længden af nogle af klassens navne var også ude af kontrol. lol.

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

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

Jeg siger ikke, at det er perfekt at bruge konventionens navngivningskonvention løsning, men det fungerede for os i et par år.

Kommentarer

• Du har ikke ‘ t forklar hvorfor.
• Ja, jeg ‘ kunne også lide denne forklaring.
• @AaronHall Overvej det som en god ting, som du ikke forstår deres valg.
• Den sædvanlige årsag er ” Nogen syntes det var en god ide “.