为什么scikit-learn中的KMeans被设计为类而非可直接调用的函数？

核心原因围绕scikit-learn的设计理念和实际使用需求展开：

• 遵循统一的Estimator接口规范
  这是scikit-learn最核心的设计原则之一，所有算法（包括聚类、分类、回归、预处理、降维等）都统一实现为Estimator类，对外提供一致的fit()、predict()、transform()等方法。用户只要掌握了一个算法的调用逻辑，就能快速复用这套逻辑使用其他所有组件，大幅降低整体学习成本。
• 方便持久化训练后的状态信息
  KMeans拟合完成后会生成大量有用的状态属性：比如簇中心cluster_centers_、训练集样本的簇标签labels_、聚类误差inertia_、迭代次数n_iter_等。用类实例承载这些状态，用户后续做新样本预测、结果分析时，直接调用实例的方法/属性即可，不需要手动保存、传递一堆零散的返回值。如果设计为纯函数，每次调用都要返回所有状态参数，使用复杂度会高很多。
• 适配生态工具链，支持参数复用
  类实例的形式可以完美适配scikit-learn的整套工具生态：比如把KMeans实例传入Pipeline搭建机器学习流水线，或者传入GridSearchCV、RandomizedSearchCV做超参数搜索，只需要实例化一次指定通用参数，就可以在多个流程中复用配置。如果是函数形式，完全没法接入这套成熟的工具链。
• 提升可维护性和扩展性
  类的封装特性可以把KMeans的内部实现逻辑（比如质心初始化策略、收敛判断逻辑、稀疏数据适配、并行计算优化等）完全隐藏在内部，对外只暴露必要的参数和方法。后续官方迭代优化算法实现时，只要对外接口保持一致，用户的存量代码不需要做任何修改即可享用更新。如果用函数实现，新增功能很容易导致参数爆炸、逻辑分支耦合，维护成本会高很多。

实际上scikit-learn底层也提供了函数式的k_means实现，但面向普通用户的顶层接口统一设计为类的形式，就是为了兼顾易用性和生态一致性。

内容的提问来源于stack exchange，提问作者John