对于"伪类型反模式",有没有理由？

Question

我有一个相对复杂的泛型类型(比如说Map<Long,Map<Integer,String>>),我在课堂内部使用它.(没有外部可见性;它只是一个实现细节.)我想在typedef中隐藏它,但Java没有这样的功能.

昨天我重新发现了以下成语,并且对于被认为是反模式感到失望.

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 */

}

当类型被隐藏并且不构成库API的一部分时(在我看来,Goetz对使用它的主要反对意见),是否有任何理由可以解决这个问题？

Answer 1

IMO,Java反模式的问题在于它们鼓励黑白思维.

实际上,大多数反模式都是微妙的.例如,链接文章解释了伪typedef如何导致API的类型签名过于严格,与特定的实现决策,病毒等相关联.但这完全是在公共API的背景下.如果你将伪typedef保留在公共API之外(即将它们限制为一个类,或者可能是一个模块),它们可能没有真正的危害,它们可能会使你的代码更具可读性.

我的观点是,你需要了解反模式,并对何时何地避免它们作出合理的判断.简单地采取"我永远不会做X因为它是一种反模式" 的立场意味着有时你会排除可接受的,甚至是好的解决方案.

Answer 2

真正的问题是这个习惯用法在你的伪typedef和你的客户端代码之间创建了一个高度耦合.但是,由于您FooBarMap私下使用,因此没有真正的耦合问题(它们是实现细节).

NB

现代Java IDE应该有助于处理复杂的泛型类型.