c++ - 所有公共方法都应该对应业务逻辑吗？

Question

所有公共方法都应该对应业务逻辑吗？

• 如果是，如何处理两个对象需要在较低的设计层进行通信，从而需要一些非业务方法公开的情况？（或者这是反模式？）
• 如果不是，如何明确区分 public 和 business public 方法？

这些是我知道的选项：

• 创建业务逻辑接口（正如 Attila 和 ArjunShankar 建议的那样）
• #define BUSINESS（在 C++ 中）然后用作BUSINESS void myMethod()- 不确定这是否是个好主意

还有其他可能吗？

Answer 1

public只是意味着类外的代码可以访问（例如调用，if 方法）成员，它与业务逻辑无关。

如果您需要将对象的接口限制为使用它的某些代码，您可以让该类实现一个仅列出所需方法的接口，并通过该接口传递对象（即方法参数的类型是接口），所以对对象进行操作的代码只能访问所需的方法

Answer 2

如果您的语言支持接口，您可以使用它来让它根据上下文公开不同的行为（如果您的语言支持多重继承，请使用它）：

Interface Kickable /* For 'business logic'.  */
  method kick (Direction)
  method dribble (Technique)

Interface PhysicsObject /* For collaboration with other objects.  */
  method collide_with (PhysicsObject)
  method fall (gravity)

Class Football Implements <Kickable, PhysicsObject>

这很干净，因为没有人可以看到他们不应该看到的方法：

Football football = new Football ();
/* Let the physics engine deal with PhysicsObjects.  */
physics_engine.add (PhysicsObject (football));

/* Let players deal with it Kickables.  */
game.set_ball (Kickable (football));

Answer 3

真的有可能知道哪些方法要在外部使用，哪些方法不应该？以我的经验，用于类之间内部通信的方法通常会随着用户需求的变化而以意想不到的方式使用。所以我首先建议编写好的单元测试来验证你的类的所有公共方法的行为。

话虽如此，C++ 中有一个成语可以实现您的目标，即 pimpl 成语：为什么要使用“PIMPL”成语？