我有一些集成（如Salesforce），我想隐藏在与产品无关的包装器后面（比如CrmService类而不是SalesforceService类）。
似乎很简单，我可以创建一个CrmService类并使用SalesforceService类作为CrmService中的实现细节，但是，有一个问题。 SalesforceService使用一些例外和枚举。如果我的CrmService抛出SalesforceExceptions或者你被要求使用Salesforce枚举，那就太奇怪了。
我有什么想法可以干净利落地完成我想要的东西吗？
编辑：目前，对于例外情况，我正在捕获Salesforce并抛出我自己的自定义。我不知道我应该为枚举做些什么。我想我可以将Salesforce枚举映射到我自己的提供者不可知的枚举，但我正在寻找一个比不必进行这种映射更清晰的通用解决方案。如果这是我的 only 选项（以映射它们），那就没关系，只是试图获得想法。
答案 0 :(得分：1)
为了利用良好的 OOP 做法，我会创建一个小的界面 ICrm，其中包含您所有CRM共有的基本成员。此界面将包含MakePayment()，GetPayments()，CheckOrder()等常规方法。还可以创建所需的枚举，例如OrderStatus或ErrorType 。
然后创建并实现实现该接口的特定类，例如： class CrmSalesForce : ICrm。在这里，您可以将特定详细信息转换为此特定CRM（在这种情况下为SalesForce）到您的常见ICrm。如果必须（http://msdn.microsoft.com/en-us/library/kxydatf9(v=vs.110).aspx），枚举可以转换为字符串，反之亦然。
然后，作为最后一步，创建您的CrmService类并在其中使用依赖注入（http://msdn.microsoft.com/en-us/library/ff921152.aspx），就是这样，传递{{1}类型}作为其构造函数中的参数（或者您喜欢的方法）。这样你就可以保持你的CrmService类非常有凝聚力和独立性，因此你可以创建和使用不同的Crm，而无需更改大部分代码。
答案 1 :(得分：1)
简短的回答是，您走在正确的轨道上，阅读Law of Demeter。
基本概念是给定对象应该假定为 关于其他任何东西的结构或性质尽可能少 （包括其子组件），按照原则 “信息隐藏”。
遵循得墨忒耳定律的优点是得到的结果 软件往往更易于维护和适应性。自从对象 较少依赖于其他对象的内部结构，对象 容器可以在不重新调整其调用者的情况下进行更改。
虽然也可能导致必须编写许多包装器 方法传播对组件的调用;在某些情况下，这可以 增加明显的时间和空间开销。
所以你看到你正在遵循一个很好的练习，我一般都会遵循这个习惯，但确实需要付出一些努力。
是的，您必须抓住并抛出自己的例外情况并映射枚举，请求和响应，这需要大量的前期工作，但如果您需要在几年内更换Salesforce，您将被视为英雄。< / p>
与软件开发的所有内容一样，如果您认为自己可能永远不会改变销售人员，那么您需要将努力与您将获得的收益相提并论？真的需要吗？ ......让你决定。