Tárgy Calisthenics fogyás osztályokhoz A beszélő bit
Blog a programozásról, főleg a PHP-ről, és talán más dolgokról
A projekt fenntartója: franiglesias. Hosted on GitHub Pages - Theme: mattgraham
írta Fran Iglesias
Ebben a cikkben bemutatunk egy gyakorlatot, amely felhasználható a kompaktabb osztályok írásának folyékonyabbá tételéhez, kifejezőbb és könnyen érthető módszerekkel.
Az objektum-kaliszténika gyakorlatok segíthetnek automatizálni azokat a gyakorlatokat, amelyek lehetővé teszik a legjobb tervezési elvek megközelítését. Bizonyos értelemben abból áll, hogy megtanulunk bizonyos hibás mintákat észlelni a kódban, és átalakítani úgy, hogy előrelépjünk a kód minőségének javítása érdekében.
Ezeknek a gyakorlatoknak az az ötlete, hogy mesterséges korlátozásokat vezessenek be a válaszok kényszerítésére, amelyek arra kényszerítenek bennünket, hogy a hagyományos megoldásokon túl gondolkodjunk.
Ebben a cikkben ezeket a korlátozásokat fogjuk alkalmazni:
- A behúzás egyetlen szintje
- Ne használjon mást
- Tartsa az egységeket kicsiben
A korlátozások
A behúzás egyetlen szintje
A behúzás egy kódszervezési modell, amely segítségével könnyen azonosíthatjuk az utasításblokkokat, amelyek elágazásokat vagy utakat képeznek a szoftverfolyamatban, valamint a kapcsolódó utasítások blokkjait. Az olyan nyelvekben, mint a Python, a behúzásnak jelentése van, ezért elkerülhetetlen. A PHP-ben és sok más nyelvben azonban a behúzás hasznos konvenció. Írhatnánk programokat behúzás nélkül, és ugyanúgy működnének, csak nehezebben olvashatóak lennének.
A behúzás jellemző a vezérlő struktúrákra, például ha/akkor:
Ennek több szintje lehet:
A kihívás ezúttal a csökkentés lesz egy a behúzás szintje egy osztály minden módszerében.
Lényegében ez arra kényszerít minket, hogy fontolóra vegyük, hogy az egyes kódblokkok mit csinálnak, és vonják ki a saját módszerébe, elmagyarázva, hogy mit tesz a nevükben.
Ne használjon mást
Az if/then/else struktúra több okból is zavaró lehet. Az egyik éppen a felesleges használata, különösen, ha az akkori láb kilépést jelent a hurokból vagy a fő módszerből.
Azért vezettem be ezt a korlátozást, mert eléggé összefügg az előzővel.
Tartsa az egységeket kicsiben
Az elején idézett cikkben entitásokról beszélünk, de jobban belegondolva inkább az egységeket tettem, hogy az osztályokra és a módszerekre egyaránt hivatkozhassak. Végső soron minden egységről szól, függetlenül attól, hogy milyen felbontást kezelünk, legyenek a lehető legkisebbek és kezelhetőbbek.
Ez bizonyos ellentmondáshoz vezet. Például egy osztály kevesebb sort foglalhat el egyetlen nagy módszerrel, mintha több kisebbre osztanánk olyan elvek alapján, mint például a behúzási szintek csökkentése. Nyilvánvalóan kompromisszumokkal járó döntésekről van szó. Az egyensúly abban rejlik, hogy az osztály és módszerei olvashatóak és érthetőek legyenek.
Kiképzés
Valamikor ezelőtt klasszikus algoritmusokat és adatstruktúrákat írtam a TDD használatával, és bár ezek viszonylag kicsi osztályok, vannak olyan struktúráik, amelyeket tovább lehetne javítani a javasolt korlátozások alkalmazásával, ezért nézzünk meg néhány példát, és hogyan tudjuk ezeket fejleszteni.
Érdekes megjegyzésként elmondani, hogy a legtöbb refaktort az IDE (PHPStorm) által biztosított eszközökkel fogom elvégezni.
Kezdjük a BubbleSort-tal, a legegyszerűbb és leg intuitívabb rendezési algoritmussal, bár sok elemnél nem túl hatékony:
A teszt egyébként ez, és a phpspec paranccsal történik:
Ebben az esetben van három behúzási szint és a korlátozás az, hogy mindegyik módszernek legfeljebb csak egy lehet. Ehhez az IDE segítségével kibontjuk a beágyazottat a saját módszerére, ügyelve arra, hogy a tesztek továbbra is sikeresek legyenek:
A teszt sikeres, tehát nem törtünk el semmit. Láthatunk néhány részletet, amelyek javíthatók ebben a kivonatban:
- A $ length paraméter felesleges, mert mivel könnyen megszerezhetjük a $ forrásból, ezért kihagyjuk.
- Használhattunk volna foreach szerkezetet a helyett .
- A tömb eleme átadható indexe helyett.
Ez egy érdekes pont: a módszer kinyerésének ténye néhány visszatükröződést okoz számunkra korábbi döntéseinkről és a kód esetleges fejlesztéseiről. Tehát a folytatás előtt néhányat alkalmazunk.
Jelenleg az elem és nem az index átadása nem tűnik életképesnek, de némi javulást elértünk, mivel most nem kell kifejezetten kiszámítanunk a $ source hosszát, ami eggyel kevesebb sort jelent, és kifejezettebbek vagyunk az ötlet, hogy bejárjuk a tömböt. Továbbra is fenntartjuk a behúzás egyetlen szintjét, amelynek szintén csak egy vonala van.
Most megvan a behúzás két szintje belül az összehasonlítóEveryElementWithCurrent módszerrel, tehát kezeljük őket ugyanúgy: kivonatolás egy módszerre.
Nos, van néhány jó dolog errefelé:
- Minden szinten csak egy szintű behúzás van.
- A metódus nevében hivatkozunk egy aktuális elemre, ezért jó lenne ezt kódban kifejezni az $ i változó nevének $ currentIndex vagy hasonlóra történő megváltoztatásával, így a hivatkozás explicit.
- Ugyanezt a bánásmódot alkalmazhatnánk a for foreach-vé konvertálásához és a $ length változó mentéséhez .