OOP类方法依赖关系



在一个类中让方法彼此依赖是可以的,方法封装在一起?这会影响单元测试吗?或者术语CCD_ 1寻址到整个类而不是类自身的方法。

可以这样做:

<?php
class foo {
protected $baz;
protected $bar;
private function checkBaz($baz) {
// do some checking
}
private function checkBar($bar) {
// do some checking
}
public function setBaz($baz) {
if($this->checkBaz($baz)){
$this->baz = $baz;
}
}
public function setBar($bar) {
if($this->checkBar($bar)){
$this->bar = $bar;
}
}
}

我在想,如果我想使用一个从这个类到另一个类的绑定方法,我必须稍微重写一下这个方法,我一直在想,让方法以某种方式封装(比如在方法参数中插入功能)是否会带来开销,这是OOP中的常见做法吗?还是我应该坚持认为类是高内聚方法和属性的封装,并将其视为一个可重用和测试Unit的整体。

是的,在类中内部调用方法是完全可以的。事实上,这是令人鼓舞的。CCD_ 3和CCD_。您只能从类中的某个需要由public方法触发的地方调用这些方法,所以是的,您的示例完全符合这些方法的使用方式。

在一般情况下以及就单元测试而言,唯一重要的是对象作为一个整体的行为方式。它的public组件很重要,这是其他代码与之交互的内容,也是其他代码所观察到的内容。无论您的对象/类进行何种内部调用,都完全取决于它自己的判断。如果它有助于你的类结构将某些代码放在单独的方法中,并向外界隐藏它们,那就顺其自然吧

是的,执行这样的方法调用非常好。它们被标记为private,因此它们仍然封装在您的类中,不暴露于外部世界。

如果这些方法调用开始导致类/对象偏离其主要目的,打破了单一责任原则,那么就值得考虑将类分解为更精细的单元,并通过依赖项注入注入这种新的依赖项。这方面的一个例子是如果checkBaz方法正在执行数据库查找。

在单元测试方面,你真正想做的是通过为你的foo类创建一个接口并实现它来对一个接口进行编程,而不是实现。这意味着无论何时你对它进行编程,你都是在对一个契约进行编程-让你可以轻松地模拟你的IFoo实现。

例如:

class Foo implements IFoo {
}

您的界面将如下所示:

interface IFoo
{
public function setBaz($baz)
public function setBar($bar)
}

我还建议遵循PEAR编码标准,并使类名首先大写。不过,如果这是你或你的团队做出的决定,那完全是你的决定。

非公共方法没有任何问题。事实上,一个类应该只导出最少量的公共方法,以允许其他类使用其服务。外部类对类的内部工作方式了解得越多,就越难在不破坏外部依赖关系的情况下更改类的内部运行方式。

应该通过间接调用来测试非公共方法。应该有一种情况,在这种情况下,每个方法最终都会被调用,即使是通过间接调用(公共方法调用私有方法等)。如果一个方法从未在单元测试中执行过,那么这是一个很好的指标,表明它实际上是死代码,可以从类中完全删除。

理论上,您可以通过子类化类并将受保护的方法提升为公共方法来直接测试类的受保护方法,但不建议这样做,因为它会暴露类的内部工作,而您并不真的想这样做。

最新更新