OO 设计原则是不是适用于 Python？

Posted 2023-02-24

【中文标题】OO 设计原则是不是适用于 Python？

【英文标题】：Do OO design principles apply to Python?OO 设计原则是否适用于 Python？

【发布时间】：2010-10-07 11:37:31

【问题描述】：

似乎许多 OO 讨论都使用 Java 或 C# 作为示例（例如 Head First Design Patterns）。

这些模式是否同样适用于 Python？或者如果我遵循设计模式，我最终会不会用 Python 编写 Java（这显然是一件非常糟糕的事情）？

【问题讨论】：

不是“显然地”：用语言 A 写成好像它是语言 B' 是一件坏事。独立于哪个是哪个。用 Perl 编写 Python 可能同样糟糕。

设计模式本身意味着与语言无关 - 一些文本可能使用特定语言来讨论实现，尽管模式意味着处于不同的抽象级别。

见***.com/questions/127377/…

【参考方案1】：

是的，您可以在 Python 中使用大量的设计模式。设计模式只是更高级别任务的可重复实现。 Python 和设计模式与其他语言的工作方式不同的原因是因为 Python 包含了大多数内置的基本模式。这意味着 Python 中出现的模式很可能是更高级别的设计模式，而不是用于通常需要哪些模式。

【参考方案2】：

简答：是的； Python 是一种面向对象的语言。

答案稍长：是的；您可以使用 OO 原则设计，然后以任何语言（甚至汇编程序）实现。

使用 OO 语言的好处是它包含对许多常见 OO 概念的支持，因此您不必冒不必要的错误风险，不得不按照惯例模拟它们。当然，总会有特定于语言的细节或多或少的适用性；你问的是“设计原则”，应该在那个细节层次上表达出来。

冗长、冗长、无聊的答案：（编程语言的发展不是简单的线性进程，但让我过分简化并忽略这个事实来做一个观察拥有大约 40 年的编程经验。）

语言特性与设计原则和模式之间总是存在着一定的关系。在每个阶段，细心的从业者都注意到：

“这是一个我们一直用当前语言手动解决的问题。”

“这是我们一直用当前语言编写的一个错误。”

“以下是我们在最佳计划中不断观察到的一些良好做法。”

因此，下一代语言倾向于为观察到的良好行为提供支持，倾向于合并概念，这样它们就不必按照约定/协议来完成（或意外地被相同破坏），并强制执行实践防止容易避免的错误。

无论我们的工具多么复杂、专业化或通用化，总有一些程序员“只是转动曲柄”，而其他人则一直在寻找“最好和最聪明”的人（在旁观者的心目中） ) 使用工具。然后他们描述和推广这些做法。正确定义（以及是否称为“风格”、“指南”、“模式”、“原则”等），这些实践最终形成了我们一直试图达到的“下一个层次”，无论我们身在何处目前站着。

【参考方案3】：

进一步考虑，一些模式，例如 Borg，可能更特定于 Python（尽管对于其他模式和语言也可以说类似的话）。

迭代器模式也在 Python 中使用，尽管形式略有不同。

Duncan Booth 写了an article on patterns in python。

【参考方案4】：

Python 有它自己的设计习惯。有些标准模式适用，有些则不适用。诸如策略或工厂之类的东西具有使它们透明的语言支持。

例如，对于一等类型，任何东西都可以是工厂。不需要工厂类型，你可以直接使用类来构造你想要的任何对象。

基本上，Python 有自己的设计习惯，它们在很大程度上有所不同，因为它非常动态并且具有令人难以置信的内省能力。

例子：

x = list
my_list = x(range(0,5)) #creates a new list by invoking list's constructor

通过将类类型分配给可调用对象，您基本上可以删除代码中的任何“工厂”类型。您只剩下可调用对象，这些可调用对象生成的对象应符合某些给定约定。

此外，Python 中的一些设计模式无法用其他静态类型语言有效地表示。元类和函数装饰器就是很好的例子。

【参考方案5】：

设计模式只不过是修复语言缺陷的胶带。

【讨论】：

我曾尝试解释我的观点，但要合理地放入 cmets 实在是太长了，所以改为：c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures

“设计模式列表和（大部分）替代它们的语言特性”。这两列都是设计模式的列表。左边是四人帮模式。右边的是其他模式，这些模式碰巧不在 GoF 书中。仍然没有看到图案是胶带。

如果您添加语言功能来替换设计模式，您只需要开发新的设计模式。我不认为语言会发展到每个解决方案都各不相同的地步。

S.Lott：诚然，我的评论可能有点过于笼统，可能你永远无法构建一种不需要设计模式的语言，但我确实认为它们是使用的代码黑客实现“缺失”的语言功能。例如，根据 Peter Norvig 的说法，Lisp 消除了 ..

虽然 Dan 口齿伶俐，但他说得有道理。更具体地说，“设计模式”运动经常解决特别有问题的 Java“缺陷”。当事物是内置和设计时，“成语”可能是一个更好的名字。

【参考方案6】：

是的，它们当然适用。但如上所述，许多模式都内置在语言中，或者与语言的更高级别特性无关。

【参考方案7】：

最大的区别在于 Python 是鸭子类型的，这意味着您不需要像在 Java 中那样详细地规划类层次结构，并且具有一流的函数。例如，当您可以只传入一个函数而不是为了模拟高阶函数而必须制作接口等时，策略模式变得更加简单和明显。更一般地说，Python 具有许多常见设计模式的语法糖，例如迭代器和上述策略。理解这些模式可能很有用（我读过 Head First 并发现它非常有用），但请考虑用 Python 方式来实现它们，而不是像在 Java 中那样做事。

【参考方案8】：

使用 Java 或 C# 可能是由于该语言的主流流行。

但无论您使用何种语言，设计原则和/或设计模式都适用。在 Python 中实现相同的设计模式显然与在 Java 或 C# 中不同。

【参考方案9】：

我想说，一旦您已经使用 Python 进行面向对象编程，它们就适用于 Python。请记住，Python 可以做的不仅仅是 OOP，您应该使用常识来选择适合该工作的范式。如果您认为您的程序最好表示为对象集合，那么请继续使用设计模式，但如果需要，请不要害怕做一些完全不同的事情。

【参考方案10】：

这取决于模式。在 Python 中有些事情很难做到：Singleton 就是一个例子。您可以将此模式替换为另一种模式，例如在 Singleton 的情况下，Borg。 在 Python 中使用设计模式并不疯狂——例如，迭代器模式已集成到语法中。然而，许多事情根本不是作为面向对象或模式繁重的东西来完成的。当 Python 最适合该任务时，它被设计为程序性或功能性的，OO 也是如此。 总的来说，我只想说用你最好的判断。如果看起来使用设计模式 Alpha-Gamma 是过度杀伤和过度复杂，那么它可能是。如果该模式看起来非常适合您想要的东西，那么它可能就是。

【讨论】：

Singleton 的价值还是值得商榷的。主题：设计模式只不过是修复语言缺陷的胶带。