【发布时间】：2016-10-20 17:39:04
【问题描述】：
我目前正在做一个项目，我将一个外部文件解析为一个抽象对象，如下所示：
public interface IMapConverter
{
IMap Convert(IMapFile file);
}
public interface IMapFile
{
void Load(string filePath);
string Json { get; }
}
我的计划是通过使用 IMapFile 实现并在该实现中创建 StreamReader 来抽象文件的加载。然后我会将其传递给 IMapConverter.Convert 方法。那会是正确的方法并保持可测试性吗？例如，将字符串直接传递给 IMapConverter 并在那里处理它是错误的吗？
【问题讨论】：
-
不清楚。对我来说
IMapFile似乎是一个糟糕的抽象，因为Json可能是一个实现细节。所有映射文件都只包含 json 吗？IMapConverter的作用是什么？它只是将json字符串解析为Map吗？看起来你的抽象有点奇怪，你可能会受益于一个更明确的设计，它试图比使用不灵活的抽象更不灵活。您能否更详细地解释您要解决的问题？ -
感谢您的评论。当然！ IMapFile 将加载一个文件，该文件可能包含字符串或二进制数据或任何内容（我明白你现在的意思了）。 IMapConverter 将转换任何格式并将其解析为包含实际地图数据的 IMap 对象，然后将其传递给 MapRenderer。你会建议什么抽象？
-
我需要更多信息来提出更好的抽象。
IMap到底是什么？它是字典数据结构的一种形式，还是Map是您所在领域的业务概念？这样的Map会有多种实现吗？Map的依赖关系是什么？创作过程复杂吗？您是否计划有多个转换器实现？转换器的作用是什么？ -
从您的业务角度来看，将地图存储在文件中是否重要？为什么不只是有一个
IMapRepository？mapRepsitory.save(map)，mapRepository.findByName(someMapName)。然后你可以实现一个FileMapRepository。我也会摆脱IMap接口。Map可能是一个实体，很少有同一种实体的多个实现，当你这样做时，你可能有一个基类并使用继承。Map也不应该在单元测试中被嘲笑，所以我认为拥有IMap接口没有用。 -
是的，当然。重要的部分是从域的角度抽象地图保存在文件中。因此，存储库公共接口不应该有任何与文件相关的内容。显然，
FileMapRepository将不得不在内部处理此类事情，并且可能依赖于其他协作对象来执行此操作（例如，不同地图格式的解析器）。您可以使用 ISP 原理并拥有类似ILoadMaps而不是MapRepository的接口。这将使您最终能够拥有ISaveMaps。
标签： c# testing abstraction solid-principles