2

我们正在设计一个仅供内部使用的库，它将作为几个即将推出的应用程序的核心业务对象模型。它主要涵盖各种类型的客户和各种类型的文档。

显然，我们希望确保如果您要使用这些对象，特别是如果您要序列化它们，它们具有有效、合理的值。

例如，客户有联系信息，其中包括电话号码。所以有一个ITelephoneNumber接口、基类、一个美国实现，所有这些。该库使用这些类来验证其数据。

但实际上，对我们来说，客户更像是一个“核心”业务对象，而电话号码则不那么重要。为电话号码编写一堆结构并将其公开为 Our-Library-Goodness 感觉有点奇怪。它们似乎有点“超出范围”。

电话号码就是一个例子；还有其他事情。我们可以将这些类结构重构为静态方法，但是我们有冗长的构造函数，他们必须“只知道”才能使用这些方法等。我们决定使用类来解决很多问题。

我的问题是

库使用者是否必须使用这些对于定义核心对象并不是真正必要的帮助类？如： 

MyCustomer.SetTelephoneNumber(new USTelephoneNumber("555", "555", "5555%$&"));
它给你编译时的反馈、他们自己的成员（AreaCode、Exchange...）等等。

或者我们是否应该将获取有效电话号码的方法留给实施，并对此更加“黑匣子”？如： 

MyCustomer.SetTelephoneNumber("555-555-5555%$&");
这只会引发错误或静默失败/成功或返回 string.Empty 或其他任何内容。

我不知道这个问题是否可以“回答”，我不想发动任何圣战。无论哪种方式，我都在寻找一些推理。我们只是一个 2 人团队，试图在一个不太关心代码质量或可维护性的机构中做正确的事情。

4

3 回答 3

1

正如您所指出的，这个问题可能无法回答。所以这不是一个答案，但是（因为评论太长了）我会在这里写：我会选择这两个选项，同时提供两个覆盖SetTelephoneNumber

How does your Customer class know how to validate the phone number as a US number? If you are assuming that a US Customer will have a US phone number, that assumption may be wrong in some cases. So it's fair both to have a "simple" override that takes care of the most likely scenario and an override that allows you to specify uncommon cases.

Your system will also become easier to test, if you can inject different types of validation logic for phone numbers instead of having them "hidden" in the class.

That said, I would not overthink this too much. It's good to "try to do the right thing" but it's also easy to fall in the FizzBuzz Enterprise Edition syndrome.

于 2013-10-03T13:30:53.173 回答
1

Phone numbers seem to be part of your domain, so expose them. Ideally, all your code in the entire app would share this phone number object and standardize on it. Maybe it should even exist at a lower layer (a data formats library or so, that is independent of higher-level objects like customers).

于 2013-10-03T13:31:28.953 回答
1

The key to this issue is that you stated it is an "internal only library." This means it is entirely up to the internal development team to determine how the library is implemented. To make those decisions, I would look at the value of the two implementation possibilities.

Does the more complex implementation save you time and effort in later development?

Does the more complex implementation keep you from writing validation code over and over when you use the library?

Those are the questions that can help you determine if the complex implementation is valuable. If the coding up front is going to save you time in the long term, then it is worth it. If the coding up front isn't going to save time and effort in the foreseeable future, then it is not worth the effort.

于 2013-10-03T13:39:36.790 回答