Hogyan írjunk hatékony módszerek (fordítása a cikk)
Hogyan írjunk hatékony módszerek (fordítása a cikk)
Ez a cikk - része a kurzus Advanced Java (Advanced Java.) A akadémia
Ez a kurzus célja, hogy segítsen kihasználni Java hatékonyabb. Tárgyalja a fejlettebb témák, mint az objektumok létrehozásához, párhuzamosítás, sorszámozás, reflexió és így tovább. Ez a tudás lesz a vezető az útra a magasból Java ismeretek.
természetesen Tartalom
1. Bevezetés
2. Az aláírás módszerei
3. A módszer a test
4. A módszer túlterhelés
5. felülírása
6. Az integráció
7. rekurzió
8. Referencia-módszer
9. Az állandóság
10. dokumentálása módszerrel
11. A módszer paraméterek és visszatérési értékek
12. Az eljárás, mint egy belépési pont az alkalmazás
13. Mi a következő lépés
14. Töltse a forráskód
1. Bevezetés
Ebben a részben a bemutató fogunk tölteni egy kis időt tárgyalja a különböző aspektusait kapcsolatos tervezési és végrehajtási módszerek a Java. Az előző részben a bemutató biztos lehet benne, hogy az írási módszerek Java - nagyon egyszerű, de sok dolog van, hogy lehet, hogy az eljárás olvashatóbb és hatékony.
2. Az eljárás aláírás
Mint már tudjuk, a Java - egy objektum-orientált nyelv. Lényegében, minden Java eljárás kifejezés bármely része egy osztály (vagy az osztály esetében a statisztikai módszer). Joga van a láthatóság (vagy elérhetőség) lehet nyilvánítani elvont vagy végleges, és így tovább. Azonban talán a legfontosabb része a módszer - az ő aláírása: a visszatérési típusa és érvek, valamint egy listát ellenőrzött kivételek végrehajtása az egyes módszerek, amelyek dobni (de ez a rész már ritkán használt, és még ritkábban ezekben a napokban). Kezdjük egy kis példa.
A fő metódus egy tömböt csak args érv és visszatér semmit. Ez nagyon jó lenne - nem ilyen egyszerű módszerekkel, mint a fő. A valóságban azonban az eljárás aláírás olvashatatlanná válhatnak. Vessünk egy pillantást az alábbi példát:
Az első dolog, ami észrevehető, hogy a szimbólumok eredetileg a nevét Java módszerek, mint setTitleVisible.Imya jól választott, és próbálják leírni a módszert jogosult.
Másodszor, a argumentumneveket mondani (vagy legalábbis hint) mintegy céljaikat. Nagyon fontos, hogy megtaláljuk a megfelelő, értelmes neveket eljárás érvek helyett int i, s karakterlánc logikai f (nagyon ritka esetekben azonban van értelme).
Harmadszor, az eljárás csak három érveket. Bár a Java sokkal nagyobb felbontású számának korlátozása érvek, erősen ajánlott, hogy ne haladja meg az argumentumok száma nagyobb, mint 6 túllépik, ami az aláírás nehéz megérteni.
Mivel a Java 5-ben megjelent, technikákat lehet egy másik listát az azonos típusú érvek (az úgynevezett varargs - változó érvekkel), és használjon egy speciális szintaxist, például:
Az alábbi példa bemutatja a kizárások részeként módszer aláírásával. A múltban, a kizárások megmutatta magát nem olyan hasznos, mint azt feltételezték, hogy eredményeként a boilerplate kód rögzítéséhez használt több mint megoldani a problémákat.
3. A módszer a test
Mindegyik módszernek megvannak a maga végrehajtását és célja létezését. Van azonban egy pár általános ajánlások, ami igazán segít, hogy írjon világos és érthető módszerekkel.
Talán a legfontosabb alapelv - a felelősség elvét az egység: meg kell próbálni, hogy végre egy olyan módszert, oly módon, hogy minden egyes eljárás során egy dolog, és csinálja is. Ezt az elvet követve, esetleg megemelve száma osztály módszerek, és fontos, hogy megtaláljuk a megfelelő egyensúlyt.
A másik fontos dolog a folyamat kódolás és a design - valósul módszerek nem rövid. Rövid módszer könnyen érthető az oka, amelyből készültek, valamint általában fér el a képernyőn, így könnyen elsajátítható az olvasónak a kódot.
Az utolsó (de nem utolsósorban) tábla segítségével van csatlakoztatva a bevallását. Ha az eljárás visszatérési érték, próbálja meg minimalizálni a helyek számát, ahol a visszatérési érték lenne esedékes (egyesek még ennél is továbbment, és javasoljuk a használatát csak egyetlen visszatérési értéke minden esetben. Minél több a visszatérési érték egy módszert, így nehezebbé válik, hogy kövesse az ő logikáját és módosítani (vagy optimalizált) végrehajtását.
4. A módszer túlterhelés
Technológiai túlterhelés módszerek gyakran használják, hogy egy speciális változata az eljárás különböző érveket, vagy ezek kombinációja. Bár a neve a módszer ugyanazon a számítógépen kiválasztja a megfelelő alternatívát merészkednek a jelenlegi értékek az érveket, hogy a hívást (a legjobb példa a Java tervezők túlterhelés: a neve mindig azonos, de különböző érveket), vagy okoz fordító hibát, ha egy ilyen változata a módszerrel nem található. Például:
Módszer túlterhelés részben hasonló a generikus (több információra generikumok megtalálható a 4. részben a bemutató Hogyan és mikor kell használni a Generics (Hogyan és mikor kell használni a generikumok)), de a túlterhelés használják az esetben, ha a megközelítés alkalmazásával generikumok nem működik jól, és mindenki vagy majdnem az érveket, amelyek a generikus igényelnek saját speciális megvalósítások. Azonban kombinálva mindkét módszer az általános és a zsúfoltság is nagyon produktív, de gyakran ez nem lehetséges, a Java, mert a típus törlődik (további részletek a 4. részben a bemutató Hogyan és mikor kell használni a Generics (Hogyan és mikor kell használni a generikumok)). Nézzünk egy példát:
Bár ezt a kódrészletet írhatnánk használata nélkül a generikus gyógyszerek, nem fontos a demonstrációs célokra. Érdekes, hogy az eljárás túlterhelt numberToString különleges végrehajtása BigDecimal és generikumok változat célja az összes többi szám.
5. felülírása
Sokat beszélgettünk arról kényszerítő módszerek 3. részében a bemutató (Hogyan tervezzünk osztályok és interfészek (Hogyan tervezzünk osztályok és interfészek). Ebben a részben már eddig is tudtunk túlterhelés módszereket fogunk mutatni miért használatát kommentárok @Override annyira fontos. A példa azt mutatja, a finom különbséget a felülírt módszer és túlterhelés módszer egy egyszerű osztály hierarchiát.
Szülő osztály csak egy módszer toObject. Hozzunk létre egy alosztálya ennek az osztálynak, és próbálja, hogy dolgozzon ki egy változata a módszer a számok konverzióját szöveggé (helyett felületű tárgyak).
Azonban az aláírás toObject módszer a származtatott osztály nem sokban különbözik (lásd Kovariáns eljárás visszatérési típus (Kovariáns visszatérő típusú módszerek) bővebben), és ez felülírja azt a superclass az osztályban, a Java fordító nem ad ki a hibákat és figyelmeztetéseket. Most nézzük egy újabb módszer a gyermek osztályban.
Ismét csak egy kis különbség a módszer aláírásával (Double helyett szám), de ebben az esetben egy túlterhelt változata a módszerrel, nem szünteti felülbírálja a szülő. Vagyis, ha a hegyét a Java fordító és @Override jelölések egybe: az eljárás jegyzetekkel az utolsó például @Override okoz fordító hibát.
6. Az integráció
Beágyazása - Ez az optimalizálás végezzük Java JIT (just in time) fordító, hogy megszüntesse az adott módszer hívást, és cserélje ki a közvetlen végrehajtása a módszer. A JIT fordító heurisztikus két dologtól függ - milyen gyakran az eljárást nevezik pillanatában, valamint, hogy van ez nagy. Módszereket, amelyek túl nagy nem lehet hatékonyan integrálni. Kódot nyújthat jelentős teljesítménynövekedést és előnye az, hogy módszereket rövid, ahogy megbeszéltük részben módszer test (módszer body).
7. rekurzió
Rekurzió Java - egy technika, ahol a módszert nevezi magát, hogy elvégezzük a számításokat. Például nézzük meg a következő példát, amely összefoglalja a száma tömböt:
Ez egy nagyon hatékony végrehajtását, de ez bizonyítja a rekurzió elég jó. Van egy jól ismert probléma a rekurzív módszer: attól függően, hogy milyen mély a hívás lánc, akkor túlcsordul a verem, ami StackOverflowError kivétel. De nem olyan rossz, mint amilyennek látszik, mert van egy technika, amely megszünteti a verem túlcsordulás, az úgynevezett farok hívás optimalizálás (optimalizálása hívás a farok). Meg lehet alkalmazni, ha a módszer farok-rekurzív (tail-rekurzív olyan módszerek, amelyben az összes rekurzív hívás farok nevezi). Például tegyük átírni az előző algoritmus farok rekurzió:
Sajnos, ebben az időben Java fordító (és a JVM JIT compiler) nem támogatja a farok hívás optimalizálás farok optimalizálás, de még ez egy nagyon hasznos technikát, és azt kell tudni, és figyelembe kell vennie, amikor írsz rekurzív algoritmusok a Java.
8. Referencia módszerek
A Java 8 tett óriási előrelépést bevezetésével funkcionális koncepciók a Java nyelven. Az alap, amely foglalkozik a módszerek az adatok, a koncepció, hogy nem támogatja a nyelvet, mielőtt (viszont mivel a Java 7 kiadását, a JVM és szabványos Java könyvtár már némi előrehaladás, hogy ez lehetséges). Szerencsére, a referencia-módszerekkel, most már lehetséges.
Nézzünk egy kis példa arra, hogy az eljárás alkalmazható más módszer érveket.
Az utolsó sorban a fő módszer egy utalás a println nyomtatásának módját minden egyes eleme egy gyűjtemény húrok a konzolra, akkor mint argumentum egy másik módszer, foreach.
9. Az állandóság
Minden hívás LocalDateTime tárgy megváltoztatja az állapotát adja vissza egy új példányt LocalDateTime, és megtartja az eredeti érintetlen. Ez egy nagy változás az API tervezési paradigma, mint a régi naptár, és dátum, (ami enyhén szólva, nem volt nagyon kellemes a használata, és okozott sok fejfájást).
10. A módszer dokumentálása
Ez egy meglehetősen bonyolult dokumentáció egy egyszerű módszerhez, például elemzéshez, de bemutatja a Javadoc eszköz néhány hasznos funkcióját, beleértve a többi osztályra mutató hivatkozásokat, a mintafragmenteket és a fejlett formázást. Így láthatja ezt a módszertani dokumentációt az Eclipse, az egyik népszerű Java IDE.
Csak a fenti képen nézve bármely Java fejlesztő a junior és a senior szint között meg tudja érteni a módszer célját és megfelelően használja azt.
11. Módszer paraméterek és visszatérési értékek
A módszerek dokumentálása nagyszerű dolog, de sajnos ez nem akadályozza meg azokat az eseteket, amikor a metódust helytelen vagy váratlan érvértékek segítségével hívják. Emiatt általában minden nyilvános módszernek meg kell erősítenie érveit, és soha nem szabad meggyőződnie arról, hogy a hívás mindig a helyes értékeket kapja (a mintát jobban ismerik, mint a józan tesztek).
Visszatérve az előző részből származó példánkhoz, a parse-módszernek meg kell vizsgálnia az egyéni érvelést, mielőtt bármit megtenné vele:
A Java a validálási és gondossági ellenőrzések másik verziójával rendelkezik, a kijelentések használatával. Azok azonban, amelyek futás közben kikapcsolhatók, és nem hajthatók végre. Előnyösebb, ha mindig végrehajtja az ilyen ellenőrzéseket és megfelelő kivételeket eredményez.
Még a dokumentált módszerek és az érvek ellenõrzése mellett, még több megjegyzést szeretnék tenni a visszaküldött értékekkel kapcsolatban. Mielőtt a Java 8 kijött volna, a legegyszerűbb módja annak, hogy azt mondják, hogy a módszer pillanatnyilag nem számít, hogy egyszerűen visszaadja a nulla értéket. Ezért van olyan rossz a Java, hogy megkapja a NullPointerException-ot. A Java 8 megpróbálja megoldani ezt a problémát az Opcionális osztály bevezetésével. Nézzük meg ezt a példát:
Az opcionális számos hasznos módszert kínál, és teljes mértékben kiküszöböli, hogy vissza kell térnie a null módszerbe, és szennyeződni kell a kódot mindenhol null ellenőrzésekkel. Az egyetlen kivétel valószínűleg a gyűjtemény. Amikor egy módszer visszaad egy gyűjteményt, akkor mindig jobb, ha null helyett null (és még opcionális) helyett a következőt is megadja:
12. A módszer beviteli pontként egy alkalmazáshoz
Még akkor is, ha egy egyszerű fejlesztő, aki egy alkalmazást ír le a szervezetedben, vagy részt vesz az egyik legnépszerűbb Java keretrendszerben vagy könyvtárban, az elkészülő tervezési döntések nagyon fontos szerepet játszanak a kód használata során.
Míg az API-k tervezésére vonatkozó módszertani útmutatások több könyvet is érintenek, a bemutató ezen része sokan foglalkozik velük (hogyan válnak a módszerek az API-ra), így az áttekintés nagyon hasznos lesz:
• Használjon értelmes neveket a módszerekhez és azok érveihez (Módszer aláírások)
Próbáld meg megtartani az argumentumok számát, hogy kevesebb legyen, mint 6 (a metódus-aláírások metszete)
• A módszereket rövidre és olvashatóan tartsa (Metszet metszete és Inlining)
• Mindig dokumentálja a nyitott módszereket, beleértve az előfeltételeket és a példákat is, ha ez értelmes (metódus-dokumentáció)
• Mindig ellenőrizze az érvek és a józanság ellenőrzéseit (Metszetparaméterek és visszatérési értékek)
• Próbálja meg elkerülni a null értéket a visszatérési értékként (szakasz Metódus paraméterek és visszatérési értékek)
• Ha van értelme, próbáljon meg változtatni a megváltoztathatatlan módszereket (amelyek nem befolyásolják a belső állapotot, az Immutability részt)
• A láthatóság és az akadálymentesítési szabályok használata olyan módszerek elrejtésére, amelyeknek nem szabad nyilvánosnak lenniük (a bemutató 3. része, az osztályok és az interfészek tervezése)
13. Mi következik?
A bemutató ezen része kevésbé beszél a Java-ról, mint nyelvről, de a Java nyelv hatékonyabb használatáról, különösen az olvasható, tiszta, dokumentált és hatékony módszerekről. A következő részben ugyanazt az alapötletet fogjuk folytatni, és megvitatjuk az általános programozási elveket, amelyek célja, hogy segítsen neked, hogy a Java fejlesztők jobban váljanak.
14. Töltse le a forráskódot
Ez volt a lecke arra, hogy hogyan lehet hatékonyan írni módszereket. A forráskódot itt töltheti le: advanced-java-part-6