Ce este un ajutor? Este un model de design? Este un algoritm?

O clasă Helper este un miros de cod mai puțin cunoscut în care un codificator a identificat câteva operații diverse, utilizate în mod obișnuit și a încercat să le facă reutilizabile prin aglomerarea lor împreună într-o grupare nefirească. Dezvoltatorii succesivi au intrat apoi în proiect și nu și-au dat seama că există clasa de ajutor și, în consecință, au rescris aceleași operațiuni comune sau chiar au creat mai multe clase de ajutor.

Dar, serios, principala problemă cu clasele de ajutor este că sunt de obicei operațiuni care acționează pe o anumită clasă, ceea ce înseamnă în mod evident în termeni OO că suferă de un caz acut de Feature Envy . Această nereușită de a împacheta comportamentul cu datele pe care acționează este motivul pentru care dezvoltatorii nu găsesc atât de des (din experiența mea).

În plus, așa cum ați identificat deja SomethingSomethingHelper este de fapt un nume teribil . Este nedescriptiv și nu vă oferă nici o idee reală despre ce fel de operații face clasa (ajută?), Ceea ce înseamnă, de asemenea, că „nu este evident atunci când adăugați noi comportamente dacă aparțin sau nu clasei Helper. Aș rupe susține astfel de clase de-a lungul liniilor de comportament conex care se grupează logic, apoi redenumesc noile clase pentru a reflecta ceea ce face.

Comentarii

• Destul de sigur că SomethingSomethingHelper nu este numele real al clasei. Dacă ‘ mirosul codului sau nu ar depinde de cât de specific clasa de ajutor este, deoarece clasele de ajutor precum Math nu sunt deloc un miros de cod.
• @RobertHarvey – Enh, majoritatea celor ‘ am văzut au fost numite SomethingSomethingHelper. La naiba, eu ‘ m uitam la o clasă numită acum HelperMethods în spațiul de nume <company>.Helpers. Pentru mine, un se află în aceeași găleată cu *Manager.
• @Telastyn: Poate că ‘ este o experiență, atunci. Am ‘ analizat clasele de asistență din proiectul meu actual (există mai multe) și toate au nume semnificative. Există ‘ doar unul care ‘ este sufixat cu Helper și cred că ‘ s pentru a-l dezambigua de la o clasă din .NET Framework având același nume. Am ‘ consider *Helper acceptabil dacă * a fost ceva semnificativ. HelperMethods este doar un eșec al imaginației; ar trebui să existe cel puțin găleți conceptuale specifice.
• @RobertHarvey – Probabil că ai ‘ dreptate. Toată cariera mea folosind limbi moderne a curățat epavele trenurilor.
• Există un subset al acestora, numit ” funcții de asistență „, care sunt de fapt utile și un model bun.De exemplu, un set comun de linii care altfel ar trebui să fie repetat într-o funcție – un exemplu de unde apar este atunci când aveți nevoie de o buclă do..while în Python, pe care limba nu acceptă ‘ (vezi al doilea exemplu aici ). O altă ar fi o structură if / elif /…/ else, dar trebuie să repetați un caz în partea de sus și de jos. Dacă este posibil, acestea ar trebui să fie localizate la funcția respectivă, și, în general, să nu fie numite de fapt ” helper „.

Un ajutor este o clasă sau metodă suplimentară inofensivă, atâta timp cât completează o componentă externă. Atunci când face contrariul, atunci indică un design defect, deoarece codul a fost exclus din autoritatea sa, dacă există vreo autoritate.

Iată un exemplu de ajutor inofensiv, folosesc o metodă numită FindRep care contorizează numărul de zerouri principale.

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

Metoda de ajutor este foarte simplă, dar foarte incomodă pentru a copia-lipi în jur și cadrul nu oferă nicio soluție.

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

Și iată un exemplu de ajutor nepotrivit:

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

Comentarii

• Arată-mi deci cum ar trebui să se facă DutchZipcodeHelper?
• @ powder366 Validate is a private metodă pe DutchZipcode

Helper este un nume de apendice utilizat în mod obișnuit.

Cu toate acestea , comunică foarte puțin a ce face. De fiecare dată când am văzut-o folosită, am găsit că este un nume suboptim.

De fapt, consider că este un miros de cod care indică mai multe probleme dedesubt.

Exemplu

Să presupunem că vedem numele ” WidgetHelper ” (aici widget ” ” este un nume de rezervă pentru orice tip de funcționalitate programabilă și nu neapărat un widget UI):

 class WidgetHelper: ...  

Ce învățăm din nume? Știm că obiectul sau funcția face un fel de lucru secundar widgetului. Din experiența mea, este posibil ca acest lucru să nu fie chiar adevărat și s-ar putea să ștergeți ” helper ” din nume și să îmbunătățiți comunicarea.

Pentru o altă posibilitate, ” WidgetHelper ” ar putea înfășura widgetul, astfel încât codul widget-ului să știe nimic despre ajutor. Implicația este că WidgetHelper în acest exemplu de pseudocod face parte din API-ul public:

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

În acest caz, ceva de genul ” WidgetAPI ” ar fi un nume mai bun, pentru că, cel puțin, informează utilizatorul relația sa cu clasa Widget. Sau poate ștergem ” Helper ” din nume și redenumim suplimentar Widget cu ceva de genul WidgetImplementation.

Alternativ, ar putea fi înfășurat și apelat de widget, ceea ce înseamnă că nu face parte din API-ul public, ci mai degrabă parte din detaliile implementării.

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

Chiar și în acest caz, cu acest cantitate mică de informații avem o îmbunătățire a ” helper. ” Ar fi mai descriptiv să-i numim un nume generic precum ” WidgetImplementation. ”

” Implementare ” poate fi corect, deoarece implementarea poate face prea mult pentru a-i da un nume mai precis. Sau poate fi el însuși prea vag – acest lucru este la discreția numitorului.

Dar așa cum am văzut, numele, ” helper, ” nu ajută la înțelegerea a ceea ce se întâmplă în cod, în afară de faptul că este accesoriu obiectului principal de interes. ” Ajutor, ” ar putea însemna multe tipuri de relații. Astfel, este prea vagă și nebuloasă și nu este potrivită în scopul informării utilizatorului despre ceea ce face obiectul.

Concluzie

Numirea lucrurilor este una dintre problemele dificile din domeniul informaticii.

Ceea ce este de dorit într-un nume este acela de a informa utilizatorul despre ceea ce ar trebui să facă. / p>

Dar în orice caz imaginabil, ar fi mai descriptiv să folosiți un alt nume decât ” helper ” sau pur și simplu îndepărtați-l cu totul.

Ca corolar pentru experiența mea și această discuție, alegerea ” helper ” într-un nume semnalează, de asemenea, efort redus sau sofisticare din partea numitorului (corect sau nu). Este, într-adevăr, un miros de cod.

Vă rugăm să nu apelați nimic unui ajutor „. ”

De fapt nici nu este.

” Helper ” este un substantiv colectiv pentru un grup de funcții.

Un ajutor este ceva care funcționează în cadrul proiectului și face un lucru mic. Acești tipi nu sunt nici măcar organizați într-o clasă, ci doar extind funcționalitatea sau capacitățile limbajului în sine. Iată ceea ce consider un foarte bun exemplu de ajutor:

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

Această funcție minusculă poate avea un impact mare asupra modului în care vă organizați codul (vă va plăcea să vă puneți literele în șiruri multiliniu), dar în sine înseamnă aproape nimic. Este „un model regex glorificat. Totuși, vă face codul mult mai ușor de citit când spuneți

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

în loc de echivalentul său pur regex.

Deci, așa sunt ajutoarele. Instrumente minuscule pentru locuri de muncă generice, care nu aparțin unei anumite clase. Puteți să le forțați într-unul (linesOf ar putea fi o metodă a unei clase de șiruri), dar unde aparțin cu adevărat este fie spațiul de nume global, fie o colecție statică de astfel de instrumente.

Desigur ” aceasta este o zonă gri, ” dar experiența mea pragmatică a fost că oamenii inventează ” ajutoare ” atunci când au identificat un set de coduri comune care le sunt utile. „Nu vreau să implementez din nou. (Unele limbi se referă la acestea ca ” mixins. „)

Problema este că codul comun este tangental legat de fiecare dintre celelalte clase pe care l-ar putea ajuta „. ” În loc să facă parte din o ierarhie de clasă strictă, doar ” îi ajută pe ” [pe toți …]. Această strategie evită duplicarea codului sursă, dar nu este lipsită de pericolele sale.

Compania mea folosea baza metodologia clasei / clasei de ajutor în care fiecare obiect ar avea două clase. Ați avea o clasă Person care conținea toate proprietățile și definițiile clasei și o clasă PersonHelper care conținea toate metodele, instrucțiunile SQL și Logica care au manipulat clasa Person. Acest lucru a funcționat bine pentru noi, deoarece toate aplicațiile noastre folosesc instrucțiuni SQL pentru a manipula date și a fost foarte ușor pentru noi să găsim și să modificăm instrucțiunile SQL după cum este necesar.

De atunci am continuat și am pus totul în clasa Persoană / Bază. Am renunțat la utilizarea convenției de numire Helper pentru că am vrut să avem mai puține fișiere în proiectele noastre. De asemenea, lungimea unora dintre numele claselor scăpa de sub control. laugh out Loud.

Nu este un exemplu grozav, dar îți vine ideea.

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

Nu spun că folosirea convenției de numire a asistentului este perfecta soluție, dar a funcționat pentru noi câțiva ani.

Comentarii

• Nu ‘ t explică de ce.
• Da, îmi place și ‘ această explicație.
• @AaronHall Consideră că este un lucru bun pe care nu îl înțelegi alegerea lor.
• Motivul obișnuit este ” Cineva a considerat că este o idee bună „.