为什么接口被描述为“是”,或“能够”verus“至少”?

时间:2011-05-24 14:32:22

标签: interface

现在我已经开始使用不需要的接口了,我终于理解了它们。

问题,为什么界面的特征被描述为“是”或“能够”与“至少是”或“至少能够”。

我认为后面的描述会帮助我更好地理解。这有意义吗?

编辑: 在掌握接口之前,如果我正在编写“Park Activity Generator”应用程序。我会有一只狗,飞盘,成人,孩子,无家可归者,鸟,垃圾等。我有限/未受过教育的设计思维总是关于事物是如何不同而不是相同的。我认为没有足够的经验来确定差异,这是一个练习 - 但确定相似之处是另一个(可能是更好的第一个?)。在将动作驱动与对象分离时,我没有动作灵活性的概念。

我相信如果我早期的开发方法没有那么缺陷,或者我看起来更难,我会早些时候达到传统的解释,但这是我发布的一个具体问题,描述了我是如何到达这个“至少一个”正如我正在探索的那样,是一个有机/愚蠢的衍生需求实现的接口。

Is this a sound approach to working with Serialized XML from a 3rd party object that I don't fully understand?

3 个答案:

答案 0 :(得分:2)

我认为这是因为在谈论真实的界面关系时,我们根本就不这么说。

狗是跑步者,或者可以跑。 (即狗实现IRunnable) 与 人类至少是一个跑步者,或者至少可以跑步。

我们倾向于用前者来说话和思考后者。

答案 1 :(得分:1)

我认为“是一种”和“能够”类型的语言来自面向对象社区使用的广泛的现实世界类比。使用一个常见的例子,在现实世界中,教师是一个人,学生是一个人,所以在编程世界中,我们说教师班的实例也是人。在对现实世界对象进行分类时,我们不会根据其功能将它们联系起来。但是,你是对的,在编程时,可以很自然地说Person的子类实例至少具有Person的功能,因为这正是多态性的处理方式。然而,这是解决问题的一种更为迫切的方法,因此可能不太可能提出。

答案 2 :(得分:1)

我更喜欢将接口视为“是 _ _er”或“是____对象”;我不同意用“can”或“has”的接口描述替换“IS”的努力,因为接口的整个点是可替代的。如果我有一个需要“顺序数据供应商”的例程,那么将要传递给我的例程的东西必须“成为”“顺序数据供应商”。它不必是List,Queue,Stack,串行端口,文件,数组或任何其他特定的基类,但它必须是“BE”的对象,可以按预期的格式顺序提供数据。