Czy istnieje kiedykolwiek uzasadnienie "antypapieru pseudo-typedef"?

Question

Mam stosunkowo skomplikowany typ ogólny (na przykład Map<Long,Map<Integer,String>>), którego używam wewnętrznie w klasie. (Nie ma zewnętrznej widoczności, to tylko szczegół implementacji.) Chciałbym ukryć to w typedef, ale Java nie ma takiego obiektu.

Wczoraj ponownie odkryłem następujący idiom i byłem rozczarowany, aby dowiedzieć się, że to considered an anti-pattern.

class MyClass 
{ 
    /* "Pseudo typedef" */ 
    private static class FooBarMap extends HashMap<Long,Map<Integer,String>> { }; 

    FooBarMap[] maps; 

    public FooBarMap getMapForType(int type) 
    { 
    // Actual code might be more complicated than this 
    return maps[type]; 
    } 

    public String getDescription(int type, long fooId, int barId) 
    { 
    FooBarMap map = getMapForType(type); 
    return map.get(fooId).get(barId); 
    } 

    /* rest of code */ 

} 

Czy kiedykolwiek być żadnego usprawiedliwienia dla tego, jeśli typ jest ukryty i nie będących częścią API biblioteki (co w moim czytaniu są główne zarzuty Goetz, aby go używać)?

Answer 1

Prawdziwym problemem jest to, że ten idiom tworzy wysokiej sprzężenia między swoim pseudo typedef i kodu klienta. Jednak od , ponieważ używasz FooBarMap prywatnie nie ma prawdziwych problemów ze sprzężeniem (są to szczegóły implementacji).

NB

Nowoczesny Java IDE powinien ostatecznie przyczynia się do czynienia ze skomplikowanymi typów generycznych.

Answer 2

Dla interfejsów publicznych nie lubię typów ogólnych, ponieważ nie mają one znaczenia. Dla mnie zobaczenie metody z argumentem HashMap < Long, Map < Integer, String >> jest podobne do tych metod C, takich jak foo (int, int, int, void *, int) i tak dalej. Posiadanie prawdziwego typu sprawia, że ​​kod jest dużo łatwiejszy do odczytania. Dla publicznego interfejsu lepiej byłoby utworzyć FooBarMap, która otacza HashMap < Long, Map < Integer, String >> zamiast "typedef", ale dla użytku wewnętrznego klasy nie widzę żadnego down-side.

Answer 3

Bez tej pseudo-typedef wolałbym napisać

private Map<Long,Map<Integer,String>>[] maps; 

i gdybym kiedyś zdecydować zrobić zmienić klasę wykonawczą z HashMap do TreeMap lub Java7GreatEnhancedWonderfulMap :-) nic nie złamie. Ale dzięki temu utkniesz w HashMap. Cóż, możesz wykonać:

interface FooBarMap extends Map<Long,Map<Integer,String>> { }; 
class FooBarHashMap extends HashMap<Long,Map<Integer,String>> implements FooBarMap{ }; 

, ale staje się coraz bardziej kłopotliwe.

Answer 4

Ma dobre zdanie na ten temat, jeśli chodzi o umieszczenie go w publicznym interfejsie. Ten idiom emuluje jakąś postać cukru syntaktycznego, nie powinien wpływać na to, co pokazujesz swoim klientom.

Ale nie widzę powodu, dla którego nie używam go lokalnie, pod warunkiem, że ułatwi ci to życie, a kod będzie bardziej czytelny - i wiesz, co robisz. Brian może generalizować i zdecydowanie przeciwstawiać mu się w każdej sytuacji, ale to jest jego poczucie Goetza: p

Answer 5

Jeśli używasz go tylko w małej zlokalizowanej jednostce kodu, problemy są małe, prawda.

Rzecz polega na tym, że zyski: Twój program prawdopodobnie nie będzie nawet tekstowo mniejszy, dopóki nie określisz pseudo-typedef 5+ razy, co oznacza, że ​​obszar, na którym jest widoczny, musi być nietrywialny.

Prawdopodobnie nie przepisałbym kodu, który to zrobił, ale wygląda na to, że nie można się do niego przyzwyczaić.

Answer 6

IMO, problem z anty-wzorcami Java polega na tym, że zachęcają do myślenia czarno-białego.

W rzeczywistości większość anty-wzorów jest dopracowana. Na przykład linkowany artykuł wyjaśnia, w jaki sposób pseudo-typedefs prowadzi do interfejsów API, których sygnatury typów są zbyt restrykcyjne, zbyt powiązane z określonymi decyzjami implementacyjnymi, wirusowymi i tak dalej. Ale wszystko to dzieje się w kontekście publicznych interfejsów API. Jeśli zachowasz pseudo-typedefs z publicznych interfejsów API (tj. Ograniczysz je do klasy lub modułu), prawdopodobnie nie wyrządzą one żadnej szkody i mogą poprawić czytelność kodu.

Chodzi mi o to, że trzeba zrozumieć anty-wzory i zrobić uzasadnieniem wyroku o tym, kiedy i gdzie się ich uniknąć. Po prostu zajęcie pozycji, że "nie będę do X, ponieważ jest to wzorzec przeciwny" oznacza, że ​​czasami można wykluczyć akceptowalne, a nawet dobre rozwiązania.