得墨忒耳定律和OOP混淆

Question

我最近一直在做一些阅读并遇到了得墨忒耳法则.现在,我读到的一些内容非常有道理,例如,报童应该永远无法通过客户口袋,抢钱包并取出钱.钱包是客户应该控制的东西,而不是报童.

是什么引发了我关于法律的问题,也许我只是误解了整个事情,将字符串属性与功能/信息的层次结合在一起是非常有用的.例如.NETs HTTPContext类.

不会编码如下:

If DataTable.Columns.Count >= 0 Then
   DataTable.Columns(0).Caption = "Something"
End If

要么

Dim strUserPlatform as string = HttpContext.Current.Request.Browser.Platform.ToString()

要么

If NewTerm.StartDate >= NewTerm.AcademicYear.StartDate And 
   NewTerm.EndDate <= NewTerm.AcademicYear.EndDate Then
   ' Valid, subject to further tests.
Else
   ' Not valid.
End If

违反这项法律？我认为(也许是错误的)OOP的重点在于提供对一个漂亮的层次结构中相关类的访问.

例如,我喜欢引用一个实用工具包的想法,该工具包可以被页面类用来避免重复性任务,例如发送电子邮件和封装有用的字符串方法:

Dim strUserInput As String = "London, Paris, New York"
For Each strSearchTerm In Tools.StringManipulation.GetListOfString(strUserInput, ",")
    Dim ThisItem As New SearchTerm
    ThisItem.Text = strSearchTerm 
Next

任何清晰度都会很好......目前我无法调和法律似乎如何消除将属性和方法串联在一起......我觉得这么多权力应该被忽视这一点似乎很奇怪？我对你们中的一些人可能已经猜到了我对OOP的新手,所以请放轻松:)

Answer 1

德米特法则(也是"函数/方法的德米特定律")想要通过说"只使用一个点"来减少是因为在一个方法中你不应该从提供的参数中假设这么多的上下文.这增加了类的依赖性并使其不太可测试.

这并不意味着您不能使用上述所有示例,但它建议客户不再使用您的方法访问钱包并从中检索钱:

function getPayment(Customer customer)
{
    Money payment = customer.leftpocket.getWallet().getPayment(100);
    ...
    // do stuff with the payment
}

您只需将paperboy所需的内容传递给方法,并因此减少方法的依赖性(如果可能):

function getPayment(Money money)
{
    // do stuff with the payment
}

您从中获益将是您不依赖于客户将钱包放在左侧口袋中,而只是处理客户给您的钱.这是你必须根据个人情况做出的决定.较少的依赖性使您可以更轻松地进行测试