Wat is een helper? Is het een ontwerppatroon? Is het een algoritme?

Een Helper-klasse is een minder bekende codegeur waar een coder een aantal verschillende, veelgebruikte bewerkingen heeft geïdentificeerd en heeft geprobeerd ze herbruikbaar te maken door ze samen te voegen samen in een onnatuurlijke groepering. Opeenvolgende ontwikkelaars zijn toen op het project gekomen en realiseerden zich niet dat de helper-klasse bestaat, en hebben bijgevolg dezelfde algemene bewerkingen herschreven, of zelfs meer Helper-klassen gemaakt.

Maar serieus, het grootste probleem met Helper-klassen is dat het gewoonlijk operaties zijn die op een specifieke klasse inwerken, wat in OO-termen uiteraard betekent dat ze lijden aan een acuut geval van Feature Envy . Dit onvermogen om het gedrag te verpakken met de gegevens waarop het handelt, is de reden waarom ontwikkelaars het zo vaak (naar mijn ervaring) niet vinden.

Bovendien is SomethingSomethingHelper, aangezien je al hebt vastgesteld, eigenlijk een vreselijke naam . Het is niet beschrijvend en geeft je geen idee van wat voor soort bewerkingen de klas doet (het helpt?), Wat ook betekent dat het bij het toevoegen van nieuw gedrag niet duidelijk is of ze in de Helper-klas thuishoren of niet. stel dergelijke klassen samen in de trant van gerelateerd gedrag die logisch samen worden gegroepeerd, en hernoem de nieuwe klassen om weer te geven wat ze doen.

Opmerkingen

• Mooi zeker dat SomethingSomethingHelper niet de werkelijke naam van de klas is. Of het ‘ een code ruikt of niet hangt af van hoe specifiek de helper class is, aangezien helper classes zoals Math helemaal geen code geur zijn.
• @RobertHarvey – Enh, de meeste van degenen die ik ‘ heb gezien dat zijn de naam SomethingSomethingHelper hebben gekregen. Hell, ik ‘ m kijk nu naar een klas met de naam HelperMethods in de <company>.Helpers naamruimte. Voor mij is een klasse bevindt zich in dezelfde bucket als *Manager.
• @Telastyn: misschien ‘ is dan een ervaring. Ik ‘ heb de helperklassen in mijn huidige project doorzocht (er zijn er meerdere), en ze hebben allemaal betekenisvolle namen. Daar ‘ is er maar één die ‘ s achtervoegsel Helper, en ik denk dat ‘ s om het te onderscheiden van een klasse in het .NET Framework met dezelfde naam. Ik ‘ vind *Helper acceptabel als * iets zinvols was. HelperMethods is gewoon een gebrek aan fantasie; er zouden op zijn minst specifieke conceptuele buckets moeten zijn.
• @RobertHarvey – Je ‘ hebt waarschijnlijk gelijk. Mijn hele carrière heb ik moderne talen gebruikt om treinwrakken op te ruimen.
• Er is een subset van deze, genaamd ” helperfuncties “, die eigenlijk handig en een goed patroon zijn.Een veelvoorkomende reeks regels die anders binnen een functie zouden moeten worden herhaald. Een voorbeeld van waar ze verschijnen is wanneer u een do..while -lus nodig hebt in Python, waarvan de taal ondersteunt niet ‘ t (zie het tweede voorbeeld hier ). Een andere is een if / elif /…/ else-structuur, maar moet bovenaan en onderaan een casus herhalen. Indien mogelijk moeten ze echter lokaal voor die functie worden gemaakt en in het algemeen niet ” helper ” worden genoemd.

Een helper is een onschadelijke aanvullende klasse of methode, zolang deze een aanvulling vormt op een externe component. Als het het tegenovergestelde doet, duidt het op een slecht ontwerp omdat de code is uitgesloten van zijn autoriteit, als er überhaupt enige autoriteit is.

Hier is een voorbeeld van een onschadelijke helper, ik gebruik een methode genaamd FindRep die het aantal voorloopnullen telt.

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

De hulpmethode is heel eenvoudig, maar erg lastig om te kopiëren en plakken en het framework biedt geen enkele oplossing.

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

En hier is een voorbeeld van een slechte helper:

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

Reacties

• Dus laat me zien hoe DutchZipcodeHelper moet worden gedaan?
• @ powder366 Valideren is een privé methode op DutchZipcode

Helper is een veelgebruikte naamaanhangsel.

, het communiceert heel weinig a over wat het doet. Elke keer dat ik het in gebruik heb gezien, heb ik ontdekt dat het een suboptimale naam is.

In feite beschouw ik het als een codegeur die wijst op meer problemen eronder.

Voorbeeld

Stel dat we de naam ” WidgetHelper ” (hier ” widget ” is een vervangende naam voor elke soort programmeerbare functionaliteit, en niet noodzakelijk een UI-widget):

 class WidgetHelper: ...  

Wat leren we van de naam? We weten dat het object of de functie een soort werk doet dat ondergeschikt is aan de widget. Het is mijn ervaring dat dit misschien niet eens waar is, en dat men de ” helper ” uit de naam zou kunnen verwijderen en de communicatie zou kunnen verbeteren.

Voor een andere mogelijkheid zou ” WidgetHelper ” de widget kunnen omhullen, zodat de widgetcode zelf het weet niets over de helper. De implicatie is dat WidgetHelper in dit pseudocodevoorbeeld deel uitmaakt van de openbare API:

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

In dit geval zou zoiets als ” WidgetAPI ” een betere naam zijn, omdat dat tenminste de gebruiker informeert over zijn relatie met de Widget-klasse. Of misschien verwijderen we ” Helper ” uit de naam en hernoemen we Widget naar iets als WidgetImplementation.

Als alternatief kan het worden ingepakt en aangeroepen door de widget, wat impliceert dat het geen deel uitmaakt van de openbare API, maar een deel van de implementatiedetails.

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

Zelfs in dit geval, met dit kleine hoeveelheid informatie hebben we een verbetering ten opzichte van ” helper. ” Het zou meer beschrijvend zijn om het een generieke naam te noemen, zoals ” WidgetImplementation. ”

” Implementatie ” kan correct zijn aangezien de implementatie te veel kan doen om het een preciezere naam te geven. Of het kan zelf te vaag zijn – dit is ter beoordeling van de naamgever.

Maar zoals we hebben gezien, de naam, ” helper, ” helpt niet “te begrijpen wat er in de code gebeurt, behalve dat het ondergeschikt is aan het belangrijkste object van interesse. ” Helper, ” kan vele soorten relaties betekenen. Het is dus overdreven vaag en vaag, en niet geschikt om de gebruiker te informeren over wat het object doet.

Conclusie

Dingen een naam geven is een van de moeilijke problemen in de informatica.

Wat wenselijk is in een naam is dat het de gebruiker informeert wat het genoemde ding moet doen.

Maar in elk geval zou het beschrijvend zijn om een andere naam te gebruiken dan ” helper ” of gewoon verwijder het helemaal.

Als uitvloeisel van mijn ervaring en deze discussie, signaleert de keuze van ” helper ” in een naam ook weinig inspanning of verfijning van de kant van de naamgever (correct of niet). Het is inderdaad een codegeur.

Noem niets een ” helper. ”

Het is eigenlijk geen van beide.

” Helper ” is een verzamelnaam voor een groep functies.

Een helper is iets dat in het hele project werkt en iets kleins doet. Deze jongens zijn vaak niet eens georganiseerd in een klas, ze breiden alleen de functionaliteit of mogelijkheden van de taal zelf uit. Dit is wat ik beschouw als een heel goed voorbeeld van een helper:

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

Deze kleine functie kan een grote invloed hebben op de manier waarop u uw code organiseert (u zult uw letterlijke lijsten graag in strings met meerdere regels plaatsen), maar op zichzelf betekent het bijna niets. Het “een veredeld regex-patroon. Toch maakt het je code een stuk leesbaarder als je zegt

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

in plaats van zijn pure regex equivalent.

Dus dat zijn wat helpers zijn. Kleine tools voor algemene taken, die niet tot een specifieke klasse behoren. Je kunt ze dwingen tot één (linesOf zou een methode van een stringklasse kunnen zijn) maar waar ze echt thuishoren is ofwel de globale naamruimte of een statische verzameling van dergelijke tools.

Thumb rule: als het nuttig is maar nergens lijkt te horen, is het waarschijnlijk een helper.

Natuurlijk ” dit is een grijs gebied, ” maar mijn pragmatische ervaring is dat mensen ” helpers ” uitvinden wanneer ze een handige set gemeenschappelijke code hebben gevonden die ze gebruiken ik wil niet opnieuw implementeren. (Sommige talen noemen deze ” mixins. “)

Het probleem is dat de algemene code tangentaal gerelateerd aan elk van de andere klassen die het ” zou kunnen helpen. ” In plaats van een deel van een strikte klassenhiërarchie, het ” helpt ” [allemaal …] hen. Deze strategie vermijdt duplicatie van broncode, maar het is niet zonder gevaren.

Mijn bedrijf gebruikte de Base class / Helper class methodologie waarbij elk object twee klassen zou hebben. U zou een Person-klasse hebben die alle klasse-eigenschappen en -definities bevat en een PersonHelper-klasse die alle methoden, SQL-statements en Logic bevat die de Person-klasse manipuleren. Dit werkte goed voor ons omdat al onze applicaties SQL-instructies gebruiken om gegevens te manipuleren en het voor ons heel gemakkelijk was om de SQL-instructies te vinden en naar behoefte aan te passen.

We zijn sindsdien verder gegaan en hebben nu alles in de klasse Persoon / Basis geplaatst. We zijn gestopt met het gebruik van de Helper-naamgevingsconventie omdat we minder bestanden in onze projecten wilden hebben. Ook liep de lengte van sommige klassenamen uit de hand. lol.

Geen goed voorbeeld, maar je snapt het wel.

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

Ik zeg niet dat het gebruik van de helper-naamgevingsconventie de perfecte oplossing is. oplossing, maar het werkte een paar jaar voor ons.

Reacties

• Je hebt ‘ t leg uit waarom.
• Ja, ik ‘ vind die uitleg ook leuk.
• @AaronHall Beschouw het als een goede zaak dat je het niet begrijpt hun keuze.
• De gebruikelijke reden is ” Iemand vond het een goed idee “.