5

背景:
私は、急速に変化する API と急速に変化するデータ モデルに依存するツールに取り組んでいます。

データ モデルと API の変更はよくあることです。ここでの問題は、コードが現在および過去のすべてのバージョンで引き続き動作する必要があることです (つまり、100% のバックワード互換性)。これは、すべてが引き続き内部で使用されるためです。

また、欠落している機能や不明な機能などが発生した場合は、正常に機能を低下させる必要があります。

ツールは、WinForms を使用して C# で記述され、カスタム ハードウェアをテストするためのものです。

<Edit>

私の目標は、機能を追加するためのクラスを作成するだけで済み、データ モデルの変更が発生したときに、API バージョンに基づいてファクトリによって作成されるデータ モデル クラスの新しいセットを作成するだけで済むようにすることです。

私にとっての課題は、将来の機能が特定のデータ モデルに依存する可能性があることです。これは、(最終的なコンボに到達するまで) 混合および一致する可能性があります。これをどのように優雅に処理しますか？

<Edit2>

もちろん、製品が出荷されたら、ツールを再利用して新しい製品用のコードを追加したいと考えています。ここに着手する前は、すべての製品サイクルはすべてのツールを (ゼロから) 書き直すことを意味していました。

</Edit>

質問:
API/データ モデルの複数のバージョンとの互換性を維持するために、どのような設計手法とパターンを提案したり、成功したりしますか?

どのような落とし穴に注意する必要がありますか?

4

7 に答える 7

4

ここでは実質的にすべてのSOLIDパターンが適用されますが、特に単一責任の原則(SRP) とオープン/クローズドの原則(OCP) が適用されます。

OCP は、型は拡張用に開いているが、変更用には閉じている必要があると具体的に述べています。

ここでも SRP は非常に役立ちます。これは、クラスが 1 つのことだけを行い、そのことが時代遅れになっても、他の多くの問題を引きずらないことを意味するからです。そのまま放置して死ぬこともできます。

より実用的なレベルでは、次の 2 つの原則に従うことをお勧めします。

TDD (または単なる包括的な単体テスト スイート) は、重大な変更から保護するのに役立ちます。

于 2009-12-23T22:25:39.670 に答える
3

役に立つかもしれないアイデアの 1 つは、Eric Evans が著書Domain Driven Designで論じている「腐敗防止層」です。このパターンの主な動機は、システムを別の変更 (および特異性) から隔離することです。

于 2009-12-24T00:17:01.800 に答える
2

コードはカスタム ハードウェアをテストするためのものだとおっしゃいました。コード (つまり、ルーチンのテスト) も変更されますか? あなたのコードは、今日は円をテストし、明日は三角形をテストしますか?それとも、日々進化している同じ基本的な円をテストしますか?

物事が動く一定のポイントがある場合は、そこから始めて、他の回答で提案されている手法を考慮して、中心にリンクするAPIとデータモデルの各バージョンのラッパーを作成します。

ただし、一定の点がなく、すべてが動く場合は、プロジェクトを放棄します。それはできません！

于 2009-12-23T23:10:03.060 に答える
1

API / データ モデルはメタデータを提供しますか? もしそうなら、これを使用してコードを API の変更から可能な限り独立させることをお勧めします。たとえば、データ モデル スキーマを使用して汎用的にデータ モデル アクセス ルーチンを生成する機会がある場合は、これを行う必要があります。もちろん、これは特定の種類の操作に対してのみ意味があります。

于 2009-12-23T23:22:48.243 に答える
0

1) 多くの単体テスト。

コードを書くときはいつでも、チェックインするために将来のバージョンが合格しなければならないコードの多くの単体テストを公開してください。

テストが機能要件に基づいていることを確認してください。つまり、関数の記述方法ではなく、他のコードを壊さないようにするために何をしなければならないかということです。

これにより、他のコードを壊すような変更をチェックインするのを防ぐことができます。

2) すべての API とデータ モデルの正式な仕様を要求する。これにより、それらがより慎重に設計され、考えや理由なしに変更が無意味にスローされることがなくなります。

于 2009-12-24T00:24:32.520 に答える
0

自分のコードと自分が制御しないものとの間のインターフェースとなる独自のラッパーを作成します。その後、ラッパーが公開する API に対してコードを記述でき、ラッパー自体の相互運用性についてのみ心配する必要があります。

于 2009-12-23T22:15:08.753 に答える
0

あなたの最善の策は、あなたが公開する API にバージョン番号を要求することです。そうすれば、作成する正しいオブジェクトを選択できます。最悪の場合、すべての変更が機能しなくなり、最終的に数十のクラスが作成されます。最良のケースは、設計がそれを処理でき、時々別のクラスになるだけです。継承はおそらくこれであなたの友達になるでしょう。肝心なのは、急速に変化する API との 100% の後方互換性を維持する必要がある場合、基本的に失敗するということです。1 つの巨大な保守不可能なクラスか、バージョニングに正しく応答するいくつかのクラスで終わることになります。

于 2009-12-23T22:17:20.923 に答える