4
像这样的代码是“火车残骸”吗(违反了得墨meter耳定律)?
浏览我编写的一些代码后,我遇到了以下使我思考的结构。乍一看,它似乎足够干净。是的,在实际代码中,该getLocation()方法的名称稍微更具体一些,可以更好地准确描述其到达的位置。 service.setLocation(this.configuration.getLocation().toString()); 在这种情况下,service是在方法中声明的已知类型的实例变量。this.configuration从传递给类构造函数开始,它是实现特定接口(强制使用公共getLocation()方法)的类的实例。因此,表达式的返回类型this.configuration.getLocation()是已知的。特别是在这种情况下,它是一个java.net.URL,而service.setLocation()想要一个String。由于这两种类型的字符串和URL不直接兼容,一些类型的转换的需要,以适应方形挂在圆孔。 但是,根据Clean Code中引用的Demeter定律,类C中的方法f应该仅调用C上的方法,由f创建或作为f的参数传递的对象以及C的实例变量中包含的对象。超出此范围的任何内容(除非是我在上面特定情况下的最终结果,除非您考虑由于方法调用本身而创建的临时对象,在这种情况下,整个法律似乎都没有意义)。toString() 考虑到列出的限制条件,为什么不鼓励或什至不允许上述呼叫,所以有合理的理由吗?还是我只是太挑剔了? 如果我要实现一种方法URLToString(),该方法只是调用作为参数传递给它toString()的URL对象(例如,由返回getLocation()),然后返回结果,则可以将getLocation()调用包装在其中以实现完全相同的结果;有效地,我只是将转换向前移了一步。那会以某种方式使其可以接受吗?(在我看来,从直觉上看,这两种方式都不应该有任何区别,因为所做的只是稍微移动一下东西。但是,按照所引用的《得墨meter耳定律》的信,这是可以接受的,因为我然后直接在函数的参数上进行操作。) 如果这比调用toString()标准类型更具有异国情调,会有所不同吗? 在回答时,请切记,更改service变量所属类型的行为或API 是不切实际的。同样,为了争辩,我们说改变返回类型getLocation()也是不切实际的。