java - 在存储在 XML 中的对象周围使用无类型包装器类，这不好吗？

Question

class MyThing {
    protected HashMap<String,Object> fields;

    protected MyThing(HashMap<String,Object> newFields){
        fields.putAll(newFields);
    }

    protected Object get(String key){
        return fields.get(key);
    }
}

现在介绍一下背景。我将此类用作一组表示来自 XML 文件的对象的不同类的父类(super class)。这基本上是一个 API 包装器的实现，我将其用作从 API 和数据库解析的 XML 之间的适配器。转换委托(delegate)给 get 方法的调用者。如果子类在创建时或返回变量时需要执行某些操作，则它们只需调用 super 然后操作之后返回的内容。例如:

class Event extends MyThing {       
    public Event(HashMap<String,Object> newFields){
        super(newFields);

        // Removes anything after an @ symbol in returned data
        Pattern p = Pattern.compile("\\@.*$");
        Matcher m = p.matcher((String)fields.get("id"));
        boolean result = m.find();

        if (result)
            fields.put("id", m.replaceFirst(""));
        }
    }

    public Object get(String key){
        Object obj = super(key);

        if (key.equals("name")){
            return "Mr./Mrs. " + ((String)obj);
        }
    }
}

我觉得我应该这样做的原因是，我不必为每个子类编写 getId、getName、getWhatever 方法，因为它们具有不同的属性。这会节省时间，而且很容易解释。

现在这显然“不像 Java”，更像是一种鸭子语言的做事方式，但是我绝对不应该这样做有合理的理由吗？

Answer 1

如果您只是因为不想使用 getter 和 setter 而达到这种复杂程度并搞砸您的对象模型，请在 Groovy 中进行相反。

Groovy 是 JVM 上的一种鸭子类型的动态语言，它接受 98% 的有效 Java 代码，因此您已经了解大部分语言(您不会失去功能)...还有“更惯用的”方法东西，但你可以随着时间的推移把它们捡起来。它也已经有一个内置的 XmlSlurper ，这可能会完成您想要做的大部分事情。

至于“你不应该的原因”，你引入了所有类型的可维护性问题。

1. 新类总是必须从基类派生。
2. 他们将不得不实现一个总是调用基础构造函数的构造函数
3. 他们将不得不覆盖 get() [你基本上用它来封装你的 getter 和 setter，为什么不直接添加那个方法并委托(delegate)给那些其他方法] 并编写可能随着时间而退化的特定逻辑.

为什么不呢？它会起作用的，对吧？当然。但这是糟糕的工程设计，因为您要么制造维护噩梦，要么重新发明轮子并且很可能做错事。