php - OOP 原则 - 如何构造类

Question

我目前有一个 Message_Repository 类，它有如下方法:

getLocationDetailsByID($messageId),
getCustomerDetailsById($messageId),
getMessages(),
updateMessageForEmail(array $data), //this takes an array which includes the message ID
getLinkIndicatorById($messageId),
setIndicator($data) //this takes an array which includes the message ID

这些方法都是数据库交互，在大多数情况下我选择各种数据，在某些情况下我进行更新。

我发现，当我充实这一点时，我的类(class)名称不再代表类(class)中发生的事情，至少不是排他性的。

最好的做法是说，一个 Location_Repository 类和一个 Customer_Repository 类将包含获取与主题相关的数据的方法吗？

仍在尝试理解单一职责。从理论上讲，这似乎很简单，但在实践中，我发现它更具挑战性，尤其是在我的类(class)不断增加和变化的情况下。绝对需要重构，但要确保我正确地考虑了这一点。

编辑我可能对我的类(class)名称感到困惑。它不是设计模式严格意义上的“存储库”，而只是我用来与数据库交互的类的命名约定。可能需要重命名它。

Answer 1

Single responsability是原子化的 OOP 概念，它导致 Encapsulation concept .

这些概念由 SOLID Principle 结合在一起，一个强大的原则，将节省您的大量时间并避免您余生的头痛:

Single responsibility principle: a class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class)

Open/closed principle “software entities … should be open for extension, but closed for modification.”

Liskov substitution principle “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.

Interface segregation principle “many client-specific interfaces are better than one general-purpose interface.”

Dependency inversion principle one should “depend upon abstractions, [not] concretions.”

如果不了解您的所有业务规则并仔细阅读您的代码，就很难分析您应该如何组织您的软件，但我会试一试:

MessageRepository 不扩展 Customer 或 Location，而是 compounded被他们。

上图中，来自维基百科的 Composition toke 示例

在 MessageRepository 的构造中，您将实例化这些类以在 MessageRepository 中使用。完美的情况是避免在类中使用公共(public)变量，并高度依赖检索和设置数据的方法(我看你已经用那种方式做了一些事情)。所以，据我所知，方法名称:

MessageRepository 方法:

• 公共(public) getMessages();
• public updateMessageForEmail(array $data);//这需要一个包含消息 ID 的数组
• public getLinkIndicatorById($messageId);
• public setIndicator($data);//这需要一个包含消息 ID 的数组

LocationRepository 方法:

• public getLocationDetailsByID($messageId);

CustomerRepository 方法:

• public getCustomerDetailsById($messageId);

重要的是要记住:您的业务规则方法应该是私有(private)的。

可读性建议:

• 避免在类名中使用下划线；
• 避免重复类名或总线。规则转化为方法。 IE。 getLocationDetailsByID 应该是 getById()，永远记住——你的方法会有实例，所以会被调用:$this->location->getById()。这同样适用于您描述的所有方法。

关于命名，这是一个很好的问题。我建议你学习设计模式/软件架构，我最喜欢的(opposing Uncle Bob perspective)是 MVC(Model-View-Controller)架构:

具有业务规则原则和数据库抽象的“存储库”应该是一个模型，因此，如果您想使用该模式，请创建 MVC 目录结构并朝着它努力!