質問は部分的に曖昧なので、この答えのいくつかは同様に必然的に曖昧です。
では、「支払い方法」をクラスとして見ることはできますか？
純粋なOOPでは、すべてがクラスまたはメソッドです。特に支払い方法が異なるため、支払い方法クラスは理にかなっています。
クラスには、合計、小計、割引、tpv選択、結果、エラーメッセージなどの属性を含めることができると思いますが、それらの一部はすでに私のバスケットクラスの一部です。
支払い方法を本質的な構成要素と行動にまで煮詰めます。次のような質問を自問してください。金額は実際に誰かが支払う方法の一部なのか、それとも支払われる金額の一部なのか。（この特定の質問への回答：これらは支払いの一部であり、支払い方法ではありません）支払いが行われると、支払い情報が必要になりますが、それを必要とする方法に渡すことができます（おそらく、買い手から売り手、Orderオブジェクト、またはOrderオブジェクトに送られる金額は、Paymentインターフェースを実装できますが、最後の金額は現実の世界を 注入的にモデル化することはできません）。
そして、それをどのように使用できますか？外部から関数を呼び出し、クレジットカードの要件などの多くのパラメータを送信しますか？または、設定ファイルで、クラスにそれらの値を外部で取得するように強制しますか？
支払要件が支払方法の一部である場合、それらは支払方法のプロパティである必要があります。支払い方法オブジェクトの初期化方法については、依存性注入手法（他の特定のクラスの中で、どの支払い方法をトランザクションに関与させて設定するかを別のクラスが決定する）を適用できますが、適用できません。 t常に最良の選択。また、構成データを読み取り、支払い方法オブジェクトを作成し、そのデータを支払い方法に渡すことで、ユーザーからのアクション（つまり、支払い方法の選択）に応答するコントローラーを作成することもできます。
支払い方法オブジェクトを使用するには、いくつかの有効なアプローチがあります。アクションに複数のオブジェクトが含まれ、1つが明確なアクター（つまり、アクションを実行する必要があるもの）でない場合は常に、適切なオブジェクトの必要なメソッドを呼び出す無料の関数（つまり非メソッド関数）を使用できます。関数の動作が複数のオブジェクトの実行時型によって異なる場合は、マルチメソッドを使用します（可能であれば、マルチメソッドをネイティブにサポートする言語は多くありませんが、次のような特定のパターンで多くの言語でシミュレートできます）。ダブルディスパッチとして）。他の可能性には、主なアクターとしてコントローラーを持つことが含まれます。
設計を実装するときに役立つ概念の1つは、機能プログラミングで明示的に作成されたアクセスルールです。オブジェクトは、作成した他のオブジェクトにアクセスできるか、既知の状態で作成された（つまり、コンストラクターに渡された）か、または導入されます。これらのルールは、依存性注入、Model-View-Controller（MVC）などの手法を通知します。
お支払い方法ごとに異なるクラス、またはそれらすべてを含む大きなクラス...
その間のどこかに。すべての支払い方法に共通するもの（アクションURLなど）はすべて基本クラスに入れる必要があります。支払い方法が一般的な動作をオーバーライドする必要がある場合、または他の方法がオーバーライドしないフィールドが必要な場合は、基本支払い方法をサブクラス化します。一貫性を保つために、すべての支払い方法の基本クラスを拡張できますが、一部のサブクラスは何もオーバーライドしない場合があります。