为什么接口被描述为“是”或“能够”？与“至少是”？
现在我已经开始在需要时使用接口，我终于理解了它们。
问题是，为什么接口的特征被描述为“是”或“能够”而不是“至少是”或“至少能够”。
我认为后面的描述会帮助我更好地理解。这有道理吗？
编辑： 在掌握接口之前，如果我正在编写一个“公园活动生成器”应用程序。我会有一只狗、飞盘、成人、儿童、无家可归者、鸟、垃圾等。我有限/未受过教育的设计思维总是关于事物如何不同而不是相同。我想没有足够的经验来认识到识别差异是一项练习，但识别相似性是另一项练习（可能是更好的第一个练习？）。我没有行动灵活性的概念，也没有将行动的驱动力与客体分开的概念。
我相信，如果我早期的开发方法没有那么有缺陷，或者我更加努力地寻找，我会更早地得出传统的解释，但这是我发布的一个具体问题，描述了我如何得出这个“至少a”作为我正在探索的有机/愚蠢的绊脚石派生需求接口的实现。
Now that I've started using interfaces out of need, I finally understand them.
Question, why are the characteristics of an interface described as "is a" or "is able to" versus "is at least a" or "is at least able to".
I think the latter descriptions would have helped me understand better. Does this make sense?
EDIT:
Before grasping interfaces, if I was writing a "Park Activity Generator" application. I would have had a Dog, Frisbee, Adults, Kids, Homeless Person, Bird, Trash etc. My limited/uneducated design thinking was always about how things are different rather than the same. I guess not enough experience to see that identifying the differences, is one exercise - but that identifying the similarities is another(and probably a better first one?). I had no concept of action flexibility, in separating the driver of action from the object.
I believe if my earlier approaches at development weren't so flawed, or I was looking harder, I would have arrived at the traditional explanation earlier, but here is a specific question I posted that sort of describes how I arrived at this "at least a" as what I'm exploring as an organically/stupid-stumbling-along derived need implementation of an interface.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为这是因为当谈论真正的接口关系时我们根本不那样说。
狗是跑步者，或者能够跑步。 （即 Dog 实现 IRunnable）
与
人类至少是一个跑步者，或者至少能够跑步。
我们倾向于用前者来说话和思考，而不是后者。
I think it's because when talking about real interface relationships we simply don't speak that way.
A dog IS A runner, or IS ABLE TO run. (ie Dog implements IRunnable)
vs.
A Human IS AT LEAST A runner, or IS AT LEAST ABLE TO run.
We tend to speak and think in terms of the former over the latter.
我认为“是”和“能够”类型的语言来自面向对象社区使用的广泛的现实世界类比。举个常见的例子，现实世界中老师是一个人，学生也是一个人，所以在编程世界中我们说Teacher类的实例也是People。在对现实世界的对象进行分类时，我们不会根据它们的功能将它们关联起来。不过，您是对的，在编程时，可以很自然地说 Person 的子类实例至少具有 Person 的功能，因为这正是处理多态性的方式。不过，这是解决问题的一种更为必要的方法，因此可能不太可能被提出。
I think the "is a" and "is able to" type of language comes from the extensive real-world analogies that the object-oriented community uses. To use a common example, in the real world a teacher is a person and a student is a person, so in the programming world we say instances of the Teacher class are also People. When classifying real-world objects, we don't relate them based on their capabilities. You're right, though, that when programming it can be perfectly natural to say that instances of subclasses of Person have at least the capabilities of a Person, since that is exactly how polymorphism is treated. That's a more imperative sort of approach to the problem, though, and it therefore is probably not as likely to be put forth.
我更喜欢将接口视为“是一个__er”或“是一个___able对象”；我不同意用“can”或“has”来替换接口描述中的“IS”，因为接口的全部要点是可替代性。如果我有一个需要“顺序数据提供者”的例程，则要传递给我的例程的内容必须“成为”“顺序数据提供者”。它不一定是列表、队列、堆栈、串行端口、文件、数组或任何其他特定的基本类型的东西，但它必须“是”一个对象可以按预期格式顺序提供数据。
I prefer to think of interfaces as saying something "is a __er" or "is an ___able object"; I disagree with the efforts to replace the "IS" from the description of interfaces with "can" or "has", because the whole point of interfaces is substitutability. If I have a routine that needs a "sequential data supplier", something that's going to be passed to my routine has to "BE" a "sequential data supplier". It doesn't have to be a List, or a Queue, or a Stack, or a serial port, or a file, or an array, or any other particular base kind of thing, but it has to "BE" an object that can supply data sequentially in the expected format.