更少的API或更多的封装?

时间:2009-09-09 10:09:40

标签: oop

3类,A包含B,B包含C.所以用户想要使用C的一些服务,有两种选择:

首先,更多封装:

class A:
    def newMethod(self):
        self.b.newMethod()

class B:
    def newMethod(self):
        self.c.newMethod()

class C:
    def newMethod(self):
        #do something
        pass

a.newMethod()

直接致电c的服务:

class A:
    pass

class B:
    pass

class C:
    def newMethod(self):
        #do something
        pass


b = a.b
c = a.c
c.newMethod()

一般来说,我从书中学到的东西告诉我,第一选择更好 但是当C有许多方法向外部用户公开时,第二选择似乎更合理。在第一个设计中,A和B没有做任何有用的事情。

你会选择什么?

1 个答案:

答案 0 :(得分:3)

让你的对象为你做事,而不是向他们询问他们的数据并用它来做事。

如果您的示例中的c暴露了很多方法,我建议您不要将这些方法暴露给a和您的客户,而是a和{{ 1}}应该合作代表客户使用这些方法。

问题的一个很好的指标是一个包含数据的类,并为这些数据项提供getter,以及访问该数据然后执行工作的客户端代码(DAO除外)。在这个(常见的)场景中,类很可能不应该暴露那些数据(并且可能打破封装),而是为该客户端做工作(通过具有该功能,或者可能是一些可注入的策略对象)。

查看Law of Demeter(链接的文档看起来相当干燥和学术性,令人遗憾),它提供了一些关于对象和成员应如何沟通的良好指导。