Mi az a segítő? Tervezési minta? Ez egy algoritmus?

A Helper osztály egy kevésbé ismert kódszag, ahol a kódoló néhány különféle, általánosan használt műveletet azonosított és megkísérelte újrafelhasználhatóvá tenni őket összegyűjtve. természetellenes csoportosításban együtt. Az egymást követő fejlesztők rátértek a projektre, és nem vették észre, hogy létezik a segítő osztály, következésképpen ugyanazokat a közös műveleteket írták át, vagy akár több Helper osztályt hoztak létre.

De komolyan, a Helper osztályok fő problémája az, hogy hogy általában olyan műveletek, amelyek egy adott osztályra hatnak, ami OO kifejezéssel nyilvánvalóan azt jelenti, hogy Feature Envy akut eseteit szenvedik. A viselkedés és az általa működtetett adatok bepakolásának hiánya miatt a fejlesztők (tapasztalataim szerint) gyakran nem találják meg.

Ezen felül, mivel már azonosította a SomethingSomethingHelper valójában egy szörnyű név . Leírhatatlan, és nem igazán sejteti, milyen típusú műveleteket végez az osztály (segít?), Ami azt is jelenti, hogy új viselkedés hozzáadásakor nem nyilvánvaló, hogy a Helper osztályba tartoznak-e vagy sem. hozzon létre olyan osztályokat a kapcsolódó viselkedés mentén, amelyek logikusan csoportosulnak, majd átnevezik az új osztályokat, hogy tükrözzék, mit csinál.

Megjegyzések

• Szép biztos, hogy a SomethingSomethingHelper nem az osztály tényleges neve. Az, hogy ‘ sa illat-e vagy sem, attól függ, hogy specifikus-e a segítő osztály, mivel a segítő osztályok, mint például a Math, egyáltalán nem kódszagok.
• @RobertHarvey – Enh, a legtöbbet én A ‘ látott nevet SomethingSomethingHelper kapta. A pokolba, I ‘ m egy HelperMethods nevű osztályt nézeget a <company>.Helpers névtérben. Nekem egy osztály ugyanabban a vödörben van, mint a *Manager.
• @Telastyn: Talán ‘ akkor egy élmény dolog. ‘ átnéztem jelenlegi projektem segítő osztályait (több is van), és mindegyiknek van értelmes neve. Csak ‘ van olyan, amelyet ‘ a Helper szóval egészít ki, és azt hiszem, hogy ‘ s, hogy megkülönböztesse a .NET-keretrendszer azonos nevű osztályától.

A segítő ártalmatlan kiegészítő osztály vagy módszer, amennyiben külső komponenst egészít ki. Ha az ellenkezőjét követi el, akkor rossz tervezést jelez, mert a kódot kizárták a jogosultságából, ha egyáltalán van jogosultság.

Itt egy példa egy ártalmatlan segítőre, egy ún. FindRep amely megszámolja a vezető nullák számát.

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

A segítő módszer nagyon egyszerű, de nagyon kényelmetlen a másolás és beillesztés, és a keretrendszer nem nyújt megoldást.

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

És itt van egy példa egy rossz segítőre:

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

Megjegyzések

• Tehát mutasd meg, hogyan kell elvégezni a DutchZipcodeHelper alkalmazást?
• @ powder366 Az érvényesítés privát módszer a DutchZipcode-on

A Helper egy általánosan használt névmelléklet.

Azonban , nagyon keveset kommunikál a hogy mit csinál. Valahányszor használtnak láttam, azt találtam, hogy ez egy optimálisabb név.

Valójában olyan kódszagnak tartom, amely több problémát jelez alatta.

Példa

Tegyük fel, hogy látjuk a ” WidgetHelper nevet ” (itt ” widget A ” bármilyen programozható funkció készenléti neve, és nem feltétlenül felhasználói felület-widget):

 class WidgetHelper: ...  

Mit tanulunk a névből? Tudjuk, hogy az objektum vagy függvény valamilyen munkát végez a widget mellett. Tapasztalatom szerint ez még valójában nem is igaz, és törölheti az ” helper ” nevet és javíthatja a kommunikációt.

Másik lehetőségként a ” WidgetHelper ” csomagolhatja a modult úgy, hogy maga a modul kód is tudja semmit a segítőről. Ennek az a következménye, hogy a WidgetHelper ebben az álkódos példában a nyilvános API része:

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

Ebben az esetben jobb név lenne valami, például: ” WidgetAPI “, mert ez legalább tájékoztatja a felhasználót a Widget osztályhoz való viszonyáról. Vagy esetleg töröljük a ” segítőt ” a névből, és ezen felül átnevezzük a Widget -t hasonlóra. WidgetImplementation.

Alternatív megoldásként becsomagolhatja és meghívhatja a widget, ami azt jelenti, hogy nem része a nyilvános API-nak, de inkább a megvalósítás részleteinek része.

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

Még ebben az esetben is ezzel kis mennyiségű információ javult a ” segítőn. ” Leíróbb lenne valamilyen általános névnek nevezni, például ” WidgetImplementation. ”

” Megvalósítás ” helyes lehet, mivel a megvalósítás túl sokat tehet, hogy pontosabb nevet adjon neki. Vagy maga is túl homályos lehet – ezt a névadó döntheti el.

De mint láttuk, a név, ” segítő, ” nem segít megérteni, mi történik a kódban, kivéve, ha ez a fő érdeklődési tárgy kiegészítő. ” Segítő, ” sokféle kapcsolatot jelenthet. Ezért túl homályos és ködös, és nem alkalmas arra, hogy tájékoztassa a felhasználót arról, hogy az objektum mit csinál.

Következtetés

A dolgok elnevezése a számítástechnika egyik nehéz problémája.

A névben az a kívánatos, hogy tájékoztassa a felhasználót arról, hogy mit kell tennie a nevezett dolognak.

De mindenesetre elképzelhető, inkább leíróbb lenne a ” helper ” vagy más név használata. távolítsa el teljesen.

Tapasztalatom és ennek a beszélgetésnek a következménye, hogy a névben szereplő ” helper ” kiválasztása szintén jelez csekély erőfeszítés vagy kifinomultság a névadó részéről (helyesen vagy nem). Valójában kódszag.

Kérjük, ne hívjon semmit ” segítőnek. ”

Ez valójában egyik sem.

” Segítő ” a funkciók csoportjának főneve.

A segítő olyan dolog, amely a projekt egészében működik és apró dolgokat művel. Ezeket a srácokat gyakran még osztályokba sem szervezik, csupán a nyelv funkcionalitását vagy képességeit bővítik. Ez az, amit nagyon jó példának tartok egy segítőnek:

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

Ez az apró funkció nagy hatással lehet a kód rendezésére (imádni fogja a szó szerinti listáit többsoros karakterláncokba tenni), de önmagában a semmi mellett jelent. “Ez dicsőíti a regex mintát. Ennek ellenére sokkal könnyebben olvashatóvá teszi a kódot, ha azt mondja, hogy

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

a tiszta regex megfelelője helyett.

Tehát ezek a segítők. Apró eszközök általános munkákhoz, nem tartoznak egy adott osztályhoz. Kényszerítheti őket egybe (a linesOf lehet egy sztring osztály metódusa), de ahova valójában tartoznak, az vagy a globális névtér, vagy az ilyen eszközök egy statikus gyűjteménye.

Természetesen ” ez egy szürke terület, ” de gyakorlati tapasztalatom az volt, hogy az emberek kitalálnak ” segédeket “, amikor azonosítottak néhány hasznos, számukra hasznos közös kódkészletet nem akarom újra megvalósítani. (Néhány nyelv ” keverékként említi ezeket. “)

A probléma az, hogy a common-kód érintőlegesen kapcsolódik az összes többi osztályhoz, hogy ” segíthet. ” Ahelyett, hogy valamilyen része lennél szigorú osztályhierarchia, csupán ” segíti ” [mindet …]. Ez a stratégia elkerüli a forráskód duplikációját, de nem veszélytelen.

A cégem a Bázist használta osztály / Segítő osztály módszertan, ahol minden objektumnak két osztálya lenne. Lenne egy Person osztálya, amely tartalmazza az osztály összes tulajdonságát és definícióját, valamint egy PersonHelper osztály, amely tartalmazza az összes metódust, SQL utasítást és logikát, amely a Person osztályt manipulálta. Ez jól működött számunkra, mert minden alkalmazásunk SQL utasításokat használ az adatok manipulálására, és nagyon könnyű volt nekünk megtalálni és módosítani az SQL utasításokat szükség szerint.

Azóta továbbléptünk, és most mindent a Person / Base osztályba soroltunk. Felhagytuk a Helper elnevezési konvenció használatát, mert kevesebb fájlt akartunk a projektjeinkben. Ezenkívül néhány osztálynév hossza már kikerült az ellenőrzés alól. lol.

Nem jó példa, de megkapja az ötletet.

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

Nem mondom, hogy a segítő elnevezési konvenció használata a tökéletes megoldás, de ez néhány évig működött nálunk.

Megjegyzések

• Nem ‘ t magyarázza el, miért.
• Igen, nekem is ‘ tetszik ez a magyarázat.
• @AaronHall Jó dolognak tartsa, amit nem ért. választásuk.
• A szokásos ok: ” Valaki jó ötletnek tartotta “.