WebHU - Programozási kérdések és válaszok

Vannak statikus és példányos metóduspárok, amelyek ugyanazokat a feladatokat hajtják végre?

Miközben egy kétdimenziós vektorosztályt fejlesztek egy matematikai könyvtár részeként, stilisztikai és használhatósági okokból fontolgatom statikus és példánymetóduspárok használatát. Vagyis két egyenértékű függvény, de az egyik statikus és nem mutáló, a másik pedig példányos és mutáló. Tudom, hogy nem én vagyok az első, aki fontolóra veszi ezt a problémát (Lásd itt például), de nem találtam olyan információt, amely közvetlenül foglalkozna vele.

A statikus és példánymetóduspárok előnyei:

  • Vannak, akik szívesebben használják az egyiket vagy a másikat, és bizonyos esetekben a választás lehetősége megkönnyíti a kód olvashatóságát.
  • Ez arra utal, hogy a statikus metódusok nem mutatnak mutációt, ha statikus és példányos módszerek is rendelkezésre állnak. Ez sokkal világosabbá teheti a hívókódot, például:

    someVector = Vector2d.add(vec1, vec2);
    someVector = (new Vector2d(vec1)).add(vec2); // does the same thing although more convoluted.
    
    // similarly adding directly to a vector is simpler with a mutator method.
    someVector.add(vec2);
    someVector = Vector2d.add(someVector, vec2);
    

    Ez különösen fontos, ha hosszú függvényhívási láncokat használunk, ami általános a vektoroknál.

  • A helyben végzett műveletek számításilag gyorsabbak lehetnek, mint minden művelethez új példányt létrehozni. A felhasználó dönti el, mikor fontos a teljesítmény. A Vector osztály felhasználói számára a teljesítmény fontos lehet, mivel a vektorokat gyakran használják a számítási szempontból költséges kódokban.

A statikus vagy példányos metódusok előnyei, de mindkettő nem:

  • Nincs jelentős kódredundancia. Könnyebb karbantartani.

  • Kevesebb puffadás. A javadok majdnem feleakkora lesz.

  • Nem szükséges tájékoztatni a felhasználókat arról, hogy a statikus módszerek soha nem, és a nem getter példányos módszerek mindig mutálódnak.

Mennyire rossz a statikus/példány módszerpárok megléte? Használják valamelyik nagyobb könyvtárban?

Széles körben ismert a „statikus metódusok nem mutálódnak, a példánymetódusok” minta?


  • Igaz, hogy egy ilyen triviálisnak tűnő osztály, mint a 2D vektor tervezése sok tervezési kihívást jelent. Különösen a kényelem és a teljesítmény (kevesebb szemét) közötti kompromisszum, valamint az idiomatikus használat és az olyan dolgok közötti kompromisszum, mint a megváltoztathatatlanság teszi ezt nehezebbé, mint első pillantásra tűnik. Eddig nem válaszolt (ha írtam egyet, akkor hosszúnak kellett lennie...), de... ha egy kicsit több kódot adsz meg (nevezetesen az egész osztályt), akkor ez jó lehet. alkalmas a következőhöz: codereview.stackexchange.com 23.11.2014
  • Lehet vitatkozni azzal, hogy a két, egyenértékű névvel rendelkező, de vad szemantikával rendelkező metódus zavaró lehet a felhasználó számára, ami finom hibákhoz vezethet. 23.11.2014

Válaszok:


1

Úgy gondolom, hogy a statikus/változatlan és a példány/változó módszereket egyaránt biztosító koncepciód jó. Úgy gondolom, hogy a megkülönböztetés könnyen elmagyarázható, és az API-felhasználók számára könnyen érthető és megjegyezhető.

Úgy gondolom, hogy az API megvalósítási kódjának nem lesz redundáns üzleti logikája. Látni fogja, hogy megismétel egy mintát, ahol a statikus megvalósítás új példányt hoz létre, és meghívja a példány metódusát azon az új példányon.

Tekintettel arra, hogy lusta vagyok, meggondolnám egy kis infrastruktúra kiépítését, amely fordításkor automatikusan generálja a statikus metódusokat, a javadoc-ot és az egységteszteket. Ez túlzás lenne, ha 10 módszered van, de nagy nyeremény, ha 1000 módszered van.

23.11.2014

2

Az első részben a "statikus metódusok nem mutálódnak", ezt széles körben használják az OOP-ban. Nem hallottam olyanról, hogy ezt kifejezetten kifejezték volna. De ez a józan ész: "Ha megváltoztat egy objektumot, miért lenne statikus a metódus, ha lehet példánymetódus?" Szóval teljesen egyetértek a "statikus metódusok nem mutálódnak"-al.

A második részben a "példánymódszerek [mutálnak]", ez valójában nem olyan széles körben használt. Ez inkább attól függ, hogy úgy dönt, hogy változatlanságot vagy változtatást alkalmaz. Példák a Java API-ból: java.lang.String változhatatlan, java.util.Date változatlan (valószínűleg véletlenül / rossz tervezés), java.lang.StringBuilder szándékosan változható (ez az a célja). A Multabilitás védelmi klónozáshoz vezethet, hogy megvédje a kódot a mutációs hibáktól. Az, hogy ez valóban probléma-e, néhány dologtól függ:

  • Ez egy olyan API, amelyet mások is fognak használni? Soha nem tudhatod, hogyan fogják használni a kódodat... IMO fontosabb az API kód ​​védelme a mutációs hibáktól, mint a normál kód.
  • Mennyire jó az egységteszt lefedettsége? Az egységtesztjei megtalálják az összes olyan mutációs hibát, amely besurranhat? Ha megfelelően követi a TDD-t (Bob bácsi 3 TDD-törvényét), és az nem API-kód, nagyon valószínűtlen, hogy a mutációs hibák besurrannak anélkül, hogy azonnal felfedeznék őket.
  • Ha van olyan kódja, amelynek védekező klónozással kell megvédenie magát a mutációs hibák ellen, milyen gyakran hívják ezt a kódot? Ha gyakran hoznak létre védekező klónokat, jobb lehet megváltoztathatatlan objektumokat használni, mint módosítható objektumokat. Alapvetően ez a csak olvasható metódusok hívásainak száma (amelyek végül védekező módon klónoznák) a társító osztályokat, szemben az osztályon lévő mutátor metódusok hívásainak számával.

Én személy szerint jobban szeretem a megváltoztathatatlan objektumokat, rajongok a final-ért (ha módosíthatnám a Java-t, akkor az final-et tenném alapértelmezettként minden mezőben és változóban, és bevezetnék egy var kulcsszót, hogy ne véglegesek legyenek), és igyekszem amennyire lehetséges, végezzen funkcionális programozást Java-ban, bár ez nem funkcionális programozási nyelv. Tapasztalataimból tudom, hogy lényegesen kevesebb időt töltök a kódom hibakeresésével, mint mások (valójában talán évente kétszer futtatom a Java hibakeresőt). Nincs elég empirikus adatom és megfelelő elemzésem ahhoz, hogy bármiféle "ok-okozati összefüggést" teremtsek a tapasztalat, a megváltoztathatatlanság, a funkcionális programozás és a helyesség között, ezért csak annyit mondok, hogy hiszek abban, hogy a megváltoztathatatlanság és a funkcionális programozás segít a helyességben, és neked kell hozzon létre saját ítéletet erről.

A második rész végén a "példánymódszerek [mutálnak]" a széles körben használt feltevés arra az esetre, ha az objektum egyébként is módosítható, különben a példánymetódusok klónoznának.

23.11.2014
Új anyagok

A rádiógomb ellenőrzött eseményének használata a jQueryben
Ebben a cikkben látni fogjuk, hogyan kell dolgozni a jquery választógombbal ellenőrzött eseményeivel. A választógombok HTML gombok, amelyek segítenek kiválasztani egyetlen értéket egy csoportból...

Körkörös függőségek megoldása terraformban adatforrásokkal – lépésről lépésre
Mi az a körkörös függőségek Dolgozzunk egy egyszerű eseten, amikor az SQS-sor és az S3-vödör közötti körkörös függőség problémája van egy egymástól függő címkeérték miatt. provider..

Miért érdemes elkezdeni a kódolást 2023-ban?
01100011 01101111 01100100 01100101 — beep boop beep boop Világunk folyamatosan fejlődik a technológia körül, és naponta fejlesztenek új technológiákat a valós problémák megoldására. Amint..

🎙 Random Noise #2  – Örökbefogadás és hit
az analitika íratlan világának gondozása Szeretné, hogy ezek a frissítések a postaládájába kerüljenek? Iratkozzon fel itt . "Ha önvezető autókat gyártanak, akkor mi miért ne..

A legrosszabb politika és prediktív modellek májátültetésre jelöltek számára az Egyesült Államokban
A máj (vagy óangolul lifer) az emberi test legnehezebb belső szervére utal, amely csendesen működik a nap 24 órájában. Mit csinál a máj? 500 feladatot hajt végre a szervezet egészségének..

5 webhely, amely 2022-ben fejleszti front-end fejlesztői készségeit
Frontendmentor.io A tényleges projektek létrehozásával a Frontendmentor.io segítséget nyújt a front-end kódolási képességeinek fejlesztésében. A kódolást azután kezdheti meg, hogy..

Mikor kell használni a Type-t az interfészhez képest a TypeScriptben?
A TypeScript a JavaScript gépelt szuperkészlete, amely statikus gépelést ad a nyelvhez. Ez megkönnyíti a robusztus és karbantartható kód írását azáltal, hogy a hibákat a fordítási időben..