我观察到，使用Python(或其他语言)时，静态主义者和机器学习科学家通常不遵循ML /数据科学项目的OOPS。
通常，这应归因于在开发用于生产的ML代码时缺乏对最佳软件工程实践的了解。因为它们主要来自数学和统计学教育背景，而不是计算机科学。
ML科学家开发临时原型(prototype)代码并由另一个软件团队将其投入生产的日子已经过去了。
问题
fit()，transform()等每个进程都提供fit_transform()，remove_missing()和outlier_removal()函数？完成此操作后，为什么通常会继承scikit-learn BaseEstimator？ 最佳答案
您对ML的一件事是正确的:数据科学家通常是聪明的人，因此他们在用代码表达想法时没有问题。问题在于他们倾向于创建即发即忘的代码，因为他们缺乏软件开发技巧-，但理想情况下并非如此。
编写代码时，代码的用途不应该有任何区别。 ML与其他任何事物一样，只是另一个 Realm ，应遵循简洁的代码原则。
最重要的方面始终应该是SOLID 。许多重要方面直接遵循:可维护性，可读性，灵活性，可测试性，可靠性等。可以添加到这些功能组合中的是变更风险。一段代码是纯ML还是银行业务逻辑或助听器的听力学算法都没有关系。都一样-实现将被其他开发人员读取，将包含要修复的错误，将被测试(希望)，并且可能进行重构和扩展。
在解决您的一些问题时，让我尝试更详细地解释这一点:
1,2)您不应认为OOP本身就是目标。如果有一个可以建模为类的概念，这会使其他开发人员更容易使用它，则可读，易于扩展，易于测试，易于避免当然-上一个类。但是除非需要，否则不要遵循BDUF反模式。从免费功能开始，并在需要时演变为更好的界面。
4)通常创建此类复杂的继承层次结构，以使实现可扩展(请参阅SOLID中的“O”)。在这种情况下，库用户可以继承BaseEstimator，很容易看出他们可以重写哪些方法以及该方法如何适合scikit的现有结构。
5)与代码几乎相同的原理，但要牢记创建/编辑这些配置文件的人员。对他们来说最简单的格式是什么？如何选择参数名称，这样即使对于刚开始使用您的产品的初学者来说，它们的含义也很明显？
所有这些事情都应该与猜测结合在一起，以猜测将来这段代码将被更改/扩展的可能性有多大？如果您确定应该一成不变地写一些东西，请不要过多地担心所有方面(例如仅关注可读性)，并将精力放在实现的更关键部分。
总结一下:考虑一下将来会与您创建进行交互的人员。如果是产品/配置文件/用户界面，则应始终“用户至上”。如果是代码，请尝试让 future 的开发人员步履蹒跚，他们将希望修复/扩展/理解您的代码。
1当然，有些特殊情况，例如由于正式法规而需要正式证明正确或广泛记录的代码，并且此主要目标强加了一些特殊的构造/实践。
关于python - 如何使用Python中的面向对象编程来构造机器学习项目？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/46990511/