作为一个对业余项目进行思考的想法实验,我一直在考虑一种方式来确保不会出现这种微妙的错误/打印错误:
这个 bug 很难被发现,因为没有编译时错误,并且你甚至在运行时也不一定会收到异常。你只会得到“意外的结果”。
为了简单地解决这个问题,我尝试使用空枚举定义。实际上是将用户 ID 作为数据类型(而不是像类或结构体那样):
public void MyMethod(int useCaseId)
{
// Do something with the useCaseId
}
public void SomeOtherMethod()
{
int userId = 12;
int useCaseId = 15;
MyMethod(userId); // Ooops! Used the wrong value!
}
这个 bug 很难被发现,因为没有编译时错误,并且你甚至在运行时也不一定会收到异常。你只会得到“意外的结果”。
为了简单地解决这个问题,我尝试使用空枚举定义。实际上是将用户 ID 作为数据类型(而不是像类或结构体那样):
public enum UseCaseId { // Empty… }
public enum UserId { // Empty… }
public void MyMethod(UseCaseId useCaseId)
{
// Do something with the useCaseId
}
public void SomeOtherMethod()
{
UserId userId = (UserId)12;
UseCaseId useCaseId = (UseCaseId)15;
MyMethod(userId); // Compile error!!
}
你觉得怎样?
int
)。这个实验的重点是看是否有一种轻量级的方式来防止意外地将错误的值传递给方法。例如,假设您的ASP.NET MVC控制器操作获取ViewModel的“UserID”属性并将其传递给“UseCaseService.CloseUseCase(int useCaseID)”方法。在这个例子中,服务类将关闭错误的用例。 - Neil Barnwell