遅い継承、将来サブクラスの動作を強制する
スーパークラスTransactionには、TransactionAとTransactionBの2つのサブクラスがあります。 Transactionは、特定のキー（ファイル、人物など）に間に合うように発生する複数のイベントで構成されます。イベントによっては、一部のトランザクションを破棄する必要があります。
ファイル「キー」の具体例は次のようになります。
TransactionAは、ファイルが読み取られている間の一連のファイルイベントを表します。TransactionReadと呼びましょうTransactionBは、書き込まれるファイルのファイルイベントのセットで、TransactionWriteと呼ばれます
同じファイルをいつでも読み書きできます。
イベントリストは次のようになります（非常に簡略化されています）。
- FileAを開く
- FileBを開く
- FileBを作成
- FileAを読み取る
- FileBに書き込む
- EOFファイルA
- FileBを読み取る
- EOFファイルB
ステップ1と2では、トランザクションはまだ不明であり、情報（タイムスタンプ、ファイル名、ユーザー名など）が必要ですが、TransactionReadかTransactionWriteかはまだわかりません。
私の合理的な方法は、イベントとメソッドを分析するのに十分なサービスを保持するTransactionクラスを作成することですwho_i_amパターンが適合する場合はREADまたはWRITEを返します（例：オープン->読み取り-> EOF）、パターンが見つからない場合はNone。
いつかトランザクションタイプがわかるようになり、TransactionをTransactionReadに変換するための良いアプローチになると思います。 Python atmでコーディングしていますが、このような概念を聞いたことがありません。悪いのはなぜですか？言語は継承を遅らせるためのツールを提供していますか？
ありがとう
- オブジェクトのクラスは作成時に認識されている必要があり、ほとんどの言語では後で変更することはできません。したがって、トランザクションを作成すると、[〜＃〜] is [〜＃〜]
Transaction（継承）; - オブジェクトが後で変更する必要がある場合は、その状態を経由する必要があります。トランザクションは[〜＃〜] have [〜＃〜]影響を受けたイベントの履歴に依存するいくつかのプロパティ/動作（構成）。
いくつかの既知の設計パターンが役立ちます。あなたの場合、私は非常によく想像できました：
- 状態パターン：
TransactionはTransactionUndetermined状態で始まり、次にTransactionReadまたはTransactionWrite状態のいずれかを取得し、最後にTransactionClosed状態を取得します、発生したイベントに応じて。公開されるインターフェースはすべての状態で同じですが、動作は動的に変化する可能性があります。 - デコレータパターン：
TransactionReadおよびTransactionWriteデコレータは、Transactionに追加の責任/動作/プロパティを追加できます。トランザクションを使用するコンテキストでは、元のオブジェクトの代わりにデコレータを使用する必要があります。すべてのデコレータは同じ基本動作（たとえば、元のオブジェクトへの関数呼び出しの転送）を実装しますが、各デコレータは追加された責任のために独自のインターフェースを公開できます。
- 状態パターン：