重构建议：映射到的POJO [英] Refactoring advice: maps to POJOs

问题描述

我目前的一个项目，其中有这样一个接口的一部分：

I currently am part of a project where there is an interface like this:

public interface RepositoryOperation {

    public OperationResult execute(Map<RepOpParam, Object> params);  
}

该界面拥有约100〜实施者。

This interface has about ~100 implementers.

要叫一个人需要做到以下几点实施者：

To call an implementer one needs to do the following:

final Map<RepOpParam, Object> opParams = new HashMap<RepOpParam, Object>();
opParams.put(ParamName.NAME1, val1);
opParams.put(ParamName.NAME2, val2);

现在我认为有明显错误的东西用任何东西＆LT;东西，对象＆gt; 通用声明

Now I think that there is obviously something wrong with anything with a<Something, Object> generic declaration.

目前这将导致主叫方 OperationImpl 来有实际读取操作的code，以了解如何构建参数映射。 （这甚至不是最严重的问题，但我并不想引用他们都因为他们是相当明显）

Currently this causes a caller of a OperationImpl to have to actually read the code of the operation in order to know how to build the argument map. (and this is not even the worst of the problems, but I don't want to cite them all since they are fairly obvious)

在一些讨论我设法说服我的同事让我做一些重构。

After some discussion I managed to convince my colleagues to let me do some refactoring.

在我看来，最简单的修复将更改界面，像这样：

It seems to me that the simplest 'fix' would be to change the interface like so:

public interface RepositoryOperation {

    public OperationResult execute(OperationParam param);  
}

在所有的具体操作将定义（扩大）自己OperationParam和需要的参数是大家可见。 （这是正常的方式做这样的事情恕我直言）

After all the concrete operations will define (extend) their own OperationParam and the needed arguments would be visible to everybody. (which is the 'normal way' to do things like that IMHO)

所以，我看到它，因为该接口实施者是相当多我有几种选择：

So as I see it since the interface implementers are quite numerous I have several choices:

1. 尝试改变界面和重写所有操作调用使用对象而不是地图。这似乎是最干净的，但我觉得，既然操作有很多，可能是在实际的工作太多了。 （〜2周可能测试）

1. Try to change the interface and rewrite all the Operation calls to use objects instead of maps. This seems the cleanest, but I think that since the operations are a lot it might be too much work in practice. (~2 weeks with tests probably)

添加一个额外的方法来像这样的接口：

Add an additional method to the interface like so:

public interface RepositoryOperation {
    public OperationResult execute(Map<String, Object> params);
    public OperationResult execute(OperationParam params);  
}

和修正地图通话时，我的功能在实施过程中遇到他们。

and fix the map calls whenever I come across them during functionality implementation.

忍受它（请不！）。

所以我的问题是。

有谁看到'固定'地图更好的方法，如果你这样做，你会解决这些问题的方法有1或2或不修复它们。

Does anyone see a better approach for 'fixing' the maps and if you do would you fix them with method 1 or 2 or not fix them at all.

编辑：
感谢伟大的答案。我会接受这两个最大的和Riduidel的答案，如果我可以，但因为我不能我倾向于多一点对Riduidel的。

Thanks for the great answers. I would accept both Max's and Riduidel's answers if I could, but since I can't I'm leaning a bit more towards Riduidel's.

推荐答案

我可以看到第三条道路。

I can see a third way.

您必须取得℃的地图; RepOpParam，对象＆gt; 。如果我理解正确的话，有什么困扰你的是，没有任何类型检查。很显然，这是不理想的。但是，它可以从整体参数（你的 OperationParam ）个人 RepOpParam 移动类型检查的问题。让我来解释吧。

You have a map made of <RepOpParam, Object>. If I understand you correctly, what bothers you is the fact that there is no type checking. And obviously, it's not ideal. But, it is possible to move the type-checking issue from the whole parameter (your OperationParam) to individual RepOpParam. Let me explain it.

假设你的 RepOpParam 接口（目前似乎是一个的标记接口）被修改，因为它：

Suppose your RepOpParam interface (which currently seems like a tagging interface) is modified as it :

public interface RepOpParam<Value> {
    public Value getValue(Map<RepOpParam, Object> parameters);
}

然后，您可以取代旧电话更新现代化code

You can then update modern code by replacing old calls to

String myName = (String) params.get(ParamName.NAME1);

新呼叫

String myName = ParamName.NAME1.getValue(params);

最明显的优势抵押品是，你现在可以为您的参数，隐藏在其本身的定义的默认值。

The obvious collateral advantage being that you can now have a default value for your parameter, hidden in its very definition.

我然而，明确指出，这第三条道路是没有什么比一个办法你的第二个方法两项业务合并成只有一个，尊重老code语言越多，同时增加在它新的力量。因此，我会personnally走第一种方式，并重写所有的东西，用现代的对象（此外，考虑采取一看配置librarires，这可能会导致你有意思anwsers这个问题）。

I have however to make clear that this third way is nothing more than a way to merge your two operations of the second way into only one, respecting old code prototype, while adding new powers in it. As a consequence, I would personnally go the first way, and rewrite all that "stuff", using modern objects (besides, consider taking a look at configuration librarires, which may lead you to interesting anwsers to this problem).

这篇关于重构建议：映射到的POJO的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！