仍在学习OOP，并试图改变我对程序生活方式的看法。我在重构时发现了很多优点，但现在我陷入了一种范式：
我正在重构购物车。当它结帐时，在我的旧PHP脚本中，我在我的函数文件中有一个函数，它将用户带到不同的付款方式（PayPal，卡，汇款等），每个付款方式都有不同的行为，价值，功能，网址等。
那么，我可以将“付款方式”视为一个类吗？
在我的旧脚本中，结帐是直线的，行动后的行动，但现在我想重新使用付款类进行预订，延期付款，订阅等，而不是跟随人类买家的点击。我认为这是OOP闪耀的时候，不是吗？
我认为Class可以有属性，如总数，小计，折扣，tpv选择，结果，错误消息......但是......其中一些已经是我的篮子类的一部分。
怎么用呢？从外部调用其功能并发送许多参数，如信用卡要求？或者强制Class在偏好文件中获取那些值？
每种付款方式的不同类别，或者包含所有付款方式的大型课程......
真的我看不到这个范例......但我几乎肯定它在那里:-)
答案 0 :(得分：2)
问题在于部分是模糊的，所以这个答案中的一部分同样含糊不清。
那么，我可以将“付款方式”视为一个类吗？
在纯OOP中，一切都是类或方法。付款方法类是有意义的，特别是因为有不同的付款方式。
我认为Class可以有属性，如总数，小计，折扣，tpv选择，结果，错误消息......但是......其中一些已经是我的篮子类的一部分。
将付款方式简化为其基本成分和行为。问问自己这样的问题：货币数量是否真的是某人如何支付的一部分，或者它们是支付的一部分？ （回答这个具体问题：它们是付款的一部分，而不是付款方式）付款时，需要付款信息，但可以将其传递给任何需要它的方法（可能在付款对象中，代表从买方发送到卖方或订单对象或订单对象的货币金额可以实现付款界面，但最后一个不会model the real world injectively）。
怎么用呢？从外部调用其功能并发送许多参数，如信用卡要求？或者强制Class在偏好文件中获取那些值？
如果付款方式是付款方式的一部分，则它们应为付款方式的属性。至于如何初始化支付方法对象，可以应用dependency injection技术（其中一个单独的类负责确定哪种支付方法，以及其他特定类应该参与交易并设置它们），尽管它并不总是最好的选择。您还可以通过读取配置数据并创建付款方式对象，将所述数据传递给付款方式，使用controller响应用户的操作（即选择付款方式）。
使用付款方式对象有几种有效的方法。每当一个动作涉及多个对象并且一个不是一个明确的actor（即应该执行动作的那个）时，你可以使用一个自由函数（即一个非方法函数）来调用必要的方法适当的对象。如果函数的行为根据多个对象的运行时类型而变化，则使用multi-methods（如果可能;本地不支持多种语言的语言，尽管您可以使用某些模式在多种语言中模拟它，例如double dispatch）。其他可能性包括将控制器作为主要角色。
在实现设计时可以提供帮助的一个概念是access rules在功能编程中明确表示：对象可以访问他们创建的其他对象，知道（即传递给他们的构造函数）或被引入。这些规则通知依赖注入，模型 - 视图 - 控制器（MVC）等技术。
每种付款方式的不同类别，或者包含所有付款方式的大型课程......
介于两者之间。所有付款方式（例如操作URL）通用的任何内容都应该放在基类中。如果付款方法需要覆盖常见行为或需要其他方法不需要的字段，则将基本付款方法子类化。为了保持一致性，您可以扩展所有付款方式的基类，尽管某些子类可能不会覆盖任何内容。
答案 1 :(得分：1)
根据您所描述的内容，我认为适合的OOP架构将沿着这些线
ShoppingCart实际上只需要知道它包含的购买量和一组可用的PaymentMethods。在结帐页面上选择付款方式时，您可以要求每个PaymentMethod都有一个名称和徽标。您还可以要求每个PaymentMethod都有一个方法，该方法显示必要的GUI，以便为处理购买集提供所需的任何信息。
我是基于我如何构建它来编写的，作为一个主要的C ++游戏程序员，所以你可能需要调整我的一些术语和方法来进行Web开发。
不要将你的程序性思维方式视为一个问题，只要认识到某些问题最好用不同的范式来解决。在这种情况下，我认为面向对象的范例非常适合这种问题。并非所有事情都必须是OOP，不是所有事情都必须是程序性的。