python中的面向对象编程 我正在读Dietel的C++程序设计书。在这本书中，他们提到程序员应该如何只发布代码的接口部分，而不发布实现

因此，将这一点带到python：

我有两个文件： 1） 实现文件=accountClass.py和 2） 接口文件=useAccountClass.py

我已经编译了实现文件并获得了.pyc文件。因此，当我向其他人提供代码时，我会向他提供.pyc文件和接口文件，对吗

另外，如果我只向其他人提供.pyc文件，我能指望他自己编写接口吗？我要说不。但我有一个令人不安的疑问：

numpy和scipy的创建者没有与我们的最终用户共享实现。我认为他们也没有共享任何接口。但是我们仍然可以在numpy和scipy中搜索不同的类及其方法。所以，用这个numpy和scipy的例子，我想我想问的是：

如果我只向其他人提供编译后的实现文件（在本例中是accountClass.pyc），那么其他人是否可以为我的代码创建接口？那个人如何知道我在实现中定义了哪些类和方法？我是说，他们会使用

if __name__ = "__main__" : 
    blah blah 

---

> P> DEETEL对C++程序员的建议不适用于Python，原因有多种：

Python不是编译成机器代码的，所以无论您以何种形式提供程序，人们阅读代码都相对容易

Python没有.h和.c文件，您只能提供.py或.pyc文件

不管怎样，把代码当作一个秘密是有点愚蠢的。您的代码中有哪些内容需要对其他人隐藏

Numpy和Scipy主要是用C实现的，这就是为什么为了方便起见，您没有源代码的原因。如果你愿意，你可以得到来源。代码的“接口”是您可以导入然后调用的模块。

您完全错了。或者这是一本可怕的书，作者有严重的错误。使用其他代码的代码确实应该遵守接口，而不关心实现的细节，除非有重要的反驳。然而，即使在机器代码的静态编译世界（例如C++），这并不意味着您应该锁定实现的源代码

是否有人可以访问实现，以及他们是否在编写特定代码时使用这些知识，这是完全不同的问题。见鬼，在处理其他代码（例如其他模块）时，即使是实现的作者也可以/应该对接口编程。类似地，即使您将实现锁定在远离某人的地方，他们也可能非常依赖于不属于接口的实现怪癖。如果在机器代码的静态编译世界中有人只提供头文件和对象文件，而不提供源代码，那是因为项目是封闭源代码的，而不是为了鼓励客户机之间的良好编程实践

在Python中，您的问题毫无意义——没有“接口”和“实现”文件，只有运行并定义函数、类和其他值的代码。您不会提供接口文件之类的东西。您提供了一个实现和（希望）文档，详细说明了接口和可能的实现细节。导入模块后，类对象、函数对象和其他对象包含大量信息（在许多情况下，包括生成大部分文档的文本）。对于像numpy这样的扩展模块也是如此。请注意，它们的实现是可访问的，只是没有包含在所有发行版中，因为它没有什么用处。对于Python代码，实际上必须分发源代码，因为其他任何内容都是特定于平台的

另一方面，.pyc文件的级别相当高，在反汇编时很容易理解（这与导入模块并在内部的任何函数上运行stdlib module

dis

一样简单）。我认为这是一个次要的技术，因为这已经是一个错误的问题了。

你不应该混淆“用户界面”和“类接口”。如果您有一个useAccountClass文件，那么该文件可能会使用accountClass文件中定义的类和方法执行某些任务，如果我理解正确的话

如果您将文件发送给其他人，他们不应该“猜测”您编译的类的功能。这就是文档的目的：描述模块中包含的函数（编译或未编译）、它们采用的参数、返回的值以及它们要执行的任务的“意义”

作为一个抽象示例，假设您有一个图像处理类。如果该类具有函数

findCircles（image）

，文档应说明它获取图像（可能包含圆），并返回图像中包含的圆心坐标列表或数组。如何检测圆并不重要，您不需要知道如何使用该功能。现在，如果调用函数像

findCircles（image，gaussian\u threshold=10）

，调用方必须知道函数使用了一些“gaussian\u threshold”参数，也就是说，调用方需要知道函数的内脏，在面向对象编程中这是不好的。如果您决定在将来使用另一种算法，那么使用该函数的所有代码都必须重写，因为

gaussian_阈值

很可能不再有意义

因此，在OOP中，接口是一种抽象，用于仅与对象通信它执行任务所需的规范参数或输入