Question

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

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

这些是我所知道的选项：

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

还有其他可能吗？

Answer 1

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

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

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 ++中有一个习惯用来实现你的目标，即成语：Why should the "PIMPL" idiom be used?

所有公共方法是否应与业务逻辑相对应？

3 个答案: