决定设计类接口

时间:2014-05-14 15:10:10

标签: oop design-patterns interface class-design object-design

我想从其他人那里得到一些关于以下问题的想法。 我们假设我们有两个类产品和项目。 Products对象允许我们访问任何Item对象。这是一个例子。

$products = new Products();

// get existing item from products
$item = $products->get(123);

// create item
$item = $products->create();
$item->setName("Some new product");
$item->setPrice(2.50);

现在更新/保存项目状态的最佳方法是什么?我看到两个选项:

$item->save();

$products->save($item);

第一个方法似乎非常直截了当。一旦设置了Item对象的属性,调用save方法就会保持更改。

另一方面,我觉得后一种方法更好。我们将两个对象的角色分开。 Item对象仅包含state,Products对象在该状态下运行。该解决方案对于编写单元测试也可能更好。 有什么想法吗?

1 个答案:

答案 0 :(得分:1)

因此,有效的项目正在缓冲实际的变化。

显然,这两种方法都可行,但这取决于您希望如何密切关注底层数据库模型或重叠对象模型。

从外部看,$item->save()在模型方面最有意义 - 正如您所指出的,您更新项目的属性然后将其保存下来。此外,它在概念上是对项目执行的操作。

然而,$products->save($item)提供了两个明显的优点,也是一个缺点。

从好的方面来说,通过将保存移动到产品中,它可以(可能)以更智能的方式处理更新的批处理/重新排序,因为它具有所有项目的可见性。它还允许将保存代码用作->add()(或多或少)

缺点是它(从对象模型视图)添加以下可能的用途,您可能不需要:

$p1 = new Products();
$p2 = new Products();
$item = $p1->create();
// set $item values
$p2->save($item);

显然,你可以添加'这是我的吗?没有?然后将错误'test'抛给Products::save,但这是阻止语法暗示可以/应该工作的用例的额外代码。或者至少可能会通过代码审查。

所以,我会说采用看起来最简单的方法并将所谓的功能($item->save())绑定到最紧密的方法,除非你需要进行缓存/批处理/任何强迫你与其他人一起使用的方法