仍在学习 OOP，并试图从程序化的生活方式改变我的观点。我在重构时发现了很多优势，但现在我陷入了一种范式：
我正在重构一个购物车。结帐时，在我的旧 php 脚本中，我的函数文件中有一个函数，该函数将用户带到不同的付款方式（PayPal、卡、汇款等），每种方式都有不同的操作、值、功能，网址等
那么，我可以将“付款方式”视为一个类吗？
在我的旧脚本中，结帐是线性的，一个接一个的动作，但现在我想重用支付类来进行预订、延期付款、订阅等，而不是跟随人工买家的点击。我认为这是 OOP 大放异彩的时候，不是吗？
我认为该类可以具有总计、小计、折扣、tpv 选择、结果、错误消息等属性......但是......其中一些已经是我的 Basket 类的一部分。
以及如何使用它？从外部调用它的函数并发送很多参数，例如信用卡要求？还是强制类在首选项文件中获取这些值？
每种付款方式都有一个不同的类别，或者是一个包含所有付款方式的大类别……
真的我看不到范式......但我几乎可以肯定它在那里:-)
这个问题在某些地方是模糊的，所以这个答案中的一些也必然是模糊的。
那么，我可以将“付款方式”视为一个类吗？
在纯 OOP 中，一切都是类或方法。支付方式类是有意义的，尤其是当有不同的支付方式时。
我认为该类可以具有总计、小计、折扣、tpv 选择、结果、错误消息等属性......但是......其中一些已经是我的 Basket 类的一部分。
将支付方式归结为它们的基本组成部分和行为。问问自己这样的问题：货币数量真的是某人支付方式的一部分，还是他们支付的一部分？（对这个特定问题的回答：它们是付款的一部分，而不是付款方式）当进行付款时，将需要付款信息，但可以将其传递给需要它的任何方法（可能在 Payment 对象中，它表示从买方发送给卖方的货币金额，或者在 Order 对象中，或者 Order 对象可以实现 Payment 接口，尽管最后一个不会单向地模拟现实世界 ）。
以及如何使用它？从外部调用它的函数并发送很多参数，例如信用卡要求？还是强制类在首选项文件中获取这些值？
如果付款要求是付款方式的一部分，则它们应该是付款方式的属性。至于如何初始化支付方法对象，可以应用依赖注入技术（其中一个单独的类负责确定在交易中应该涉及哪种支付方法以及其他特定类并设置它们），尽管它不是t 始终是最佳选择。您还可以有一个控制器，通过读取配置数据并创建支付方式对象，将所述数据传递给支付方式，来响应用户的操作（即选择支付方式）。
有几种有效的方法可以使用支付方式对象。任何时候一个动作涉及多个对象并且一个对象不是明确的参与者（即应该执行该动作的那个），您可以使用一个自由函数（即一个非方法函数）来调用适当对象的必要方法。如果函数的行为因多个对象的运行时类型而异，您将使用多方法（如果可能；没有多少语言本身支持多方法，尽管您可以使用具有某些模式的多种语言来模拟它，例如作为双重调度）。其他可能性包括将控制器作为主要参与者。
在实现设计时可以提供帮助的一个概念是在能力编程中明确的访问规则：对象可以访问它们创建的、知道创建（即传递给它们的构造函数）或被引入的其他对象。这些规则通知诸如依赖注入、模型-视图-控制器 (MVC) 等技术。
每种付款方式都有一个不同的类别，或者是一个包含所有付款方式的大类别……
中间某个地方。所有支付方式通用的任何东西（例如操作 URL）都应该放在基类中。如果支付方式需要覆盖常见行为或需要其他方法不需要的字段，则子类化基本支付方式。为了一致性起见，您可以扩展所有支付方式的基类，尽管某些子类可能不会覆盖任何东西。
根据您所描述的，我认为适合的 OOP 架构将遵循这些思路
ShoppingCart 只需要知道它包含的 Purchases 和一组可用的 PaymentMethods。您可以要求每个 PaymentMethod 在结帐页面上选择付款方式时显示名称和徽标。您还可以要求每个 PaymentMethod 有一个方法来显示必要的 GUI，以便向其提供处理购买集所需的任何信息。
我是根据我如何构建它来写这篇文章的，不过作为一个主要的 C++ 游戏程序员，所以你可能需要调整我的一些术语和方法来进行 Web 开发。
不要将你的程序思维方式视为一个问题，只要认识到某些问题最好用不同的范式来解决。在这种情况下，我认为面向对象的范式非常适合这类问题。并非所有事情都必须是 OOP，但也不是所有事情都必须是程序性的。