Mikä on auttaja? Onko se suunnittelumalli? Onko se algoritmi?

Helper-luokka on vähemmän tunnettu koodihaju, jossa kooderi on tunnistanut muutamia yleisesti käytettyjä toimintoja ja yrittänyt tehdä niistä uudelleenkäytettäviä kertomalla ne yhdessä luonnottomassa ryhmittymässä. Peräkkäiset kehittäjät ovat sitten tulleet projektiin eivätkä tajuaneet, että auttajaluokka on olemassa, ja ovat sen vuoksi kirjoittaneet samat yhteiset toiminnot tai jopa luoneet lisää Helper-luokkia.

Mutta vakavasti, Helper-luokkien pääongelma on että ne ovat yleensä toimintoja, jotka vaikuttavat tiettyyn luokkaan, mikä OO: n termeillä tarkoittaa ilmeisesti sitä, että he kärsivät akuutista Feature Envy -tapauksesta. Tämä epäonnistuminen käyttäytymisen ja sen sisältämien tietojen pakkaamisessa on, miksi kehittäjät eivät niin usein (kokemukseni mukaan) löydä sitä.

Tämän lisäksi, koska olet jo tunnistanut, että SomethingSomethingHelper on todella kauhea nimi . Se ei ole kuvaileva eikä anna mitään oikeaa tietoa siitä, minkälaisia toimintoja luokka tekee (se auttaa?), Mikä tarkoittaa myös, että se ei ole ilmeistä uutta käyttäytymistä lisäämällä, kuuluvatko he Helper-luokkaan vai eivät. koota sellaiset luokat toisiinsa liittyvän käyttäytymisen mukaisesti, jotka ryhmittyvät loogisesti yhteen, ja nimeä uudet luokat sen mukaan, mitä ne tekevät.

Kommentit

• Melko varmista, että SomethingSomethingHelper ei ole luokan todellinen nimi. Hajuako se ’ sa-koodista vai ei, riippuu siitä, kuinka spesifinen auttajaluokka on, koska auttajaluokat, kuten Math, eivät ole lainkaan koodihaju.
• @RobertHarvey – Enh, useimmat niistä minä ’ Näet , jotka on nimetty SomethingSomethingHelper. Helvetti, I ’ m tarkastelee luokkaa, jonka nimi on HelperMethods nimitilassa <company>.Helpers. Minulle -luokka on samassa ryhmässä kuin *Manager.
• @Telastyn: Ehkä se ’ s sitten kokemus asia. ’ Olen käynyt läpi nykyisen projektini auttajaluokat (niitä on useita), ja niillä kaikilla on merkitykselliset nimet. Siellä ’ on vain yksi, johon ’ liitetään Helper, ja luulen, että ’ s erottaaksesi sen .NET Frameworkin luokasta, jolla on sama nimi. Pidän ’ pidän *Helper hyväksyttävää, jos * oli jotain mielekästä. HelperMethods on vain mielikuvituksen epäonnistuminen; Siellä pitäisi olla ainakin erityisiä käsitteellisiä ämpärejä.
• @RobertHarvey – Sinulla on ’ oikeastaan oikeassa. Koko urani nykyaikaisia kieliä käyttäen on ollut siivota junahylkyjä.
• Näistä on osa-alue, nimeltään ” auttajafunktiot ”, jotka ovat todella hyödyllisiä ja hyvä malli.Esimerkiksi yhteinen rivijoukko, joka muuten olisi toistettava funktion sisällä – yksi esimerkki siitä, missä ne näkyvät, on, kun tarvitset do..while -silmukan Pythonissa, jonka kieli ei tue ’ t (katso toista esimerkkiä täältä ). Toinen olisi if / elif /…/ else -rakenne, mutta täytyy toistaa tapaus ylä- ja alaosassa. Jos mahdollista, ne on kuitenkin tehtävä paikallisiksi kyseiselle toiminnolle, eikä niitä yleensä kutsuta ” auttajaksi ”.

Auttaja on vaaraton lisäluokka tai -menetelmä, kunhan se täydentää ulkoista komponenttia. Kun se tekee päinvastoin, se ilmoittaa virheellisestä suunnittelusta, koska koodi on suljettu sen valtuutuksesta, jos sellaista on.

Tässä on esimerkki vaarattomasta auttajasta, käytän menetelmää nimeltä FindRep, joka laskee etunollien lukumäärän.

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

Helper-menetelmä on hyvin yksinkertainen, mutta kopioiminen ja liittäminen on erittäin hankalaa eikä kehys tarjoa mitään ratkaisua.

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

Ja tässä on esimerkki huonosta auttajasta:

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

Kommentit

• Joten näyttää minulle, miten DutchZipcodeHelper tulisi tehdä?
• @ powder366 Vahvista on yksityinen method on DutchZipcode

Helper on yleisesti käytetty nimiliite.

Kuitenkin , se kommunikoi hyvin vähän a mitä se tekee. Joka kerta kun olen nähnyt sen käytetyn, olen huomannut sen olevan optimaalista alempi nimi.

Pidän sitä itse asiassa koodihaisuna, joka osoittaa enemmän ongelmia alla.

Esimerkki

Oletetaan, että näemme nimen ” WidgetHelper ” (tässä ” -widget ” on stand-in-nimi kaikenlaisille ohjelmoitaville toiminnoille, eikä välttämättä käyttöliittymän widgetille:

 class WidgetHelper: ...  

Mitä opimme nimestä? Tiedämme, että esine tai toiminto tekee jonkinlaista työtä widgetin toissijaisena. Kokemukseni mukaan tämä ei ehkä edes ole totta, ja voidaan poistaa ” auttaja ” nimestä ja parantaa viestintää.

Toinen mahdollisuus on, että ” WidgetHelper ” voi kääriä widgetin niin, että itse widget-koodi tietää ei mitään auttajasta. Tarkoituksena on, että WidgetHelper tässä pseudokoodiesimerkissä on osa julkista sovellusliittymää:

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

Tässä tapauksessa jotain ” WidgetAPI ” olisi parempi nimi, koska se ainakin ilmoittaa käyttäjälle sen suhteen Widget-luokkaan. Tai ehkä poistamme ” Helper ” nimestä ja nimeämme lisäksi Widget sellaiseksi WidgetImplementation.

Vaihtoehtoisesti widget voi kääriä sen ja kutsua sen, mikä tarkoittaa, että se ei ole osa julkista sovellusliittymää, mutta pikemminkin osa toteutuksen yksityiskohtia.

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

Jopa tässä tapauksessa tällä pienellä määrällä tietoa meillä on parannus ” auttajaan. ” Olisi kuvailevampaa kutsua sitä jollekin yleisnimelle, kuten ” WidgetImplementation. ”

” Toteutus ” voi olla oikea, koska toteutus voi tehdä liikaa antaa sille tarkemman nimen. Tai se voi itse olla liian epämääräinen – tämä on nimittäjän harkinnan mukaan.

Mutta kuten olemme nähneet, nimi, ” auttaja, ” ei auta ymmärtämään mitä koodissa tapahtuu, paitsi että se on tärkeän kiinnostavan kohteen liitännäinen. ” Helper, ” voi tarkoittaa monenlaisia suhteita. Siksi se on liian epämääräinen ja epäselvä eikä sovellu hyvin käyttäjälle tiedottamiseen kohteen toiminnasta.

Päätelmä

Asioiden nimeäminen on yksi tietojenkäsittelytieteen vaikeista ongelmista.

Nimessä on toivottavaa, että se ilmoittaa käyttäjälle, mitä nimetyn asian on tarkoitus tehdä.

Mutta joka tapauksessa kuviteltavissa, olisi kuvailevampaa käyttää muuta nimeä kuin ” auttaja ” tai yksinkertaisesti poista se kokonaan.

Kokemukseni ja tämän keskustelun seurauksena myös nimessä ” auttaja ” valinta antaa signaalin. nimittäjän vähäinen vaivannäkö tai hienostuneisuus (oikein tai ei). Se on todellakin koodihaju.

Älä kutsu mitään ” auttajaksi. ”

Se ei todellakaan ole kumpikaan.

” Apulainen ” on funktioryhmän yhteinen substantiivi.

Apulainen on jotain, joka toimii koko projektissa ja tekee pienen asian. Nämä kaverit eivät useinkaan ole edes järjestetty luokkiin, he vain laajentavat itse kielen toiminnallisuutta tai ominaisuuksia. Tässä pidän erittäin hyvää esimerkkiä auttajasta:

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

Tällä pienellä toiminnolla voi olla suuri vaikutus siihen, miten järjestät koodisi (rakastat laittaa kirjaimelliset luettelosi monirivisiksi merkkijonoiksi), mutta sinänsä se tarkoittaa ei mitään. Se ”kirkastaa regex-mallia. Silti se tekee koodistasi paljon luettavamman, kun sanot

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

sen puhtaan regex-vastaavuuden sijaan.

Joten auttajat ovat. Pienet työkalut yleisiin töihin, jotka eivät kuulu tiettyyn luokkaan. Voit pakottaa ne yhdeksi (linesOf voi olla menetelmä merkkijonoluokaksi), mutta mihin ne todella kuuluvat, on joko globaali nimiavaruus tai yksi staattinen kokoelma tällaisia työkaluja.

Peukalosääntö: jos se on hyödyllinen, mutta ei näytä kuuluvan mihinkään, se on todennäköisesti auttaja.

Tietenkin ” tämä on harmaa alue, ” mutta käytännön kokemukseni on ollut, että ihmiset keksivät ” auttajia ”, kun he ovat tunnistaneet heille hyödyllisen joukon yhteisiä koodeja, joita he eivät luovuta ”ei halua toteuttaa uudelleen. (Jotkut kielet kutsuvat näitä ” miksauksiksi. ”)

Ongelmana on, että common-koodi on tangentiaalisesti liittynyt kaikkiin muihin luokkiin, joista se saattaa ” auttaa. ” Sen sijaan, että se olisi osa tiukka luokkahierarkia, se vain ” auttaa ” [kaikkia …] heitä. Tämä strategia välttää lähdekoodien päällekkäisyyksiä, mutta se ei ole vaarattomia.

Yritykseni käytti Base-ohjelmaa class / Helper -luokan metodologia, jossa jokaisella objektilla olisi kaksi luokkaa. Sinulla olisi Person-luokka, joka sisälsi kaikki luokan ominaisuudet ja määritelmät, ja PersonHelper-luokka, joka sisälsi kaikki Person-luokan manipulointimenetelmät, SQL-käskyt ja logiikan. Tämä toimi meille hyvin, koska kaikki sovelluksemme käyttävät SQL-käskyjä tietojen manipulointiin, ja meidän oli erittäin helppo löytää ja muokata SQL-käskyjä tarpeen mukaan.

Olemme sittemmin siirtyneet eteenpäin ja asettaneet kaiken Henkilö / Perus-luokkaan. Lopetimme Helper-nimeämiskäytännön, koska halusimme, että projekteissamme olisi vähemmän tiedostoja. Myös joidenkin luokkien nimien pituus oli menossa käsistä. LOL.

Ei loistava esimerkki, mutta saat idean.

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

En sano, että auttajan nimeämiskäytännön käyttö on täydellinen ratkaisu, mutta se toimi meille muutaman vuoden.

Kommentit

• Et ’ t selitä miksi.
• Kyllä, pidän siitä myös ’.
• @AaronHall Pidä sitä hyvänä asiana, jota et ymmärrä heidän valintansa.
• Tavallinen syy on ” Joku ajatteli sen olevan hyvä idea ”.