我一直在阅读关于用多态重构和替换条件语句的信息。我遇到的麻烦是，只有在您遇到更复杂的情况（没有多态性，您将不得不多次重复相同的switch语句或if-els）时，这对我才有意义。如果您只做一次，我看不出有什么意义-您必须在某个地方设置条件，对吗？
作为示例，我最近编写了以下类，该类负责读取XML文件并将其数据转换为程序的对象。我们支持的文件有2种可能的格式，因此我仅在类中编写了一种方法来处理每种文件，并使用大小写转换来确定要使用的文件格式：
public class ComponentXmlReader
{
public IEnumerable<UserComponent> ImportComponentsFromXml(string path)
{
var xmlFile = XElement.Load(path);
switch (xmlFile.Name.LocalName)
{
case "CaseDefinition":
return ImportComponentsFromA(xmlFile);
case "Root":
return ImportComponentsFromB(xmlFile);
}
}
private IEnumerable<UserComponent> ImportComponentsFromA(XContainer file)
{
//do stuff
}
private IEnumerable<UserComponent> ImportComponentsFromB(XContainer file)
{
//do stuff
}
}
据我所知，我可以为此编写一个类层次结构来进行解析，但是我在这里看不到优势-我仍然必须使用大小写转换来确定要实例化的类。在我看来，这将是毫无益处的额外复杂性。如果我要保留这些类，并根据文件类型对它们进行更多操作，则可以避免在多个位置进行相同的切换，但这是一次性的。这是正确的吗，还是我没有看到某些原因或技术使使用多态类层次结构执行此操作成为一个好主意？
与所有设计选择一样，上下文是关键。在这种情况下，您似乎拥有一个相当简单的类来处理两个非常相似的任务。如果两个Import方法包含很少的重复代码，那么将它们包含在一个类中可能是最好的选择，因为正如您所说的那样，它可以降低复杂性。
但是，将来可能会使用此类，甚至还会添加新的导入类型。在这种情况下，如果该类是多态的，则它将更加可重用。
此外，由于这些方法听起来非常相似，因此您可能会有一堆重复的代码，您可以将它们保留在基类中，仅将特定于导入的代码放在子类中。
另外，正如Carl所提到的，有许多不使用case语句来实现此逻辑的方法。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句