2

いくつかの Web アプリケーションで使用されているフレックス コンポーネントを開発しました。一部のコールバックが古く、引数が正しくないことがわかりました。たとえば、あるパラメーターを設定するために使用される場合、1 つのオブジェクトを使用し、同じパラメーターを取得する場合は別のオブジェクトを使用します。これらの関数は、パラメータの設定と取得において一貫したものにしたいと考えています。そこで、新しい名前と適切なパラメーターを使用して、それらに関する新しいゲッターとセッターの開発を開始することを考えました。とにかく、コンポーネントは他の多くのアプリケーションで使用されているため、コールバックの名前を変更したり、実装を変更したりすることはできません。他の Web アプリケーションで問題が発生する可能性があります。そのため、Flash で公開されたコールバックを非推奨にする方法があるかどうかを知りたいのですが、これらのメソッドを使用している人々はいくつかの警告を見て、廃止されていないバージョンで代用し始めるでしょう. 回答ありがとうございます。

4

2 に答える 2

4

かつての API は、常に API です。

API から何かを削除することはできません。そうしないと、現在それらのコマンドを使用しているアプリが失敗します。新しい代替 API を追加し、古いものを保持するだけです。古いものは非推奨であり、より良いコマンドがあることをドキュメントに記載してください。

この例は、jQuery のlive()andで、delegate()これは に置き換えられましたon()。非推奨ですが、特にライブラリをアップグレードしたが、古くてメンテナンスされていないプラグインを使用している人のために、古い API に対応するために 1.7 にまだ存在していますlive()。delegate()

このようにすることもできます。古い API の同じインターフェースを明らかにすることができますが、その下では新しい API 実装を使用していますが、少し変更が加えられています。そうすれば、コードを繰り返す必要がなくなります。

delegate()たとえば、jQuerylive()とon(). delegate()これらはこれらのメソッドの実際のコードではありませんが、私は非推奨の概念に従っています ( 、live()および以外の非推奨の例は考えられませんon())。

//the three have different set-ups
.live(event,callback);
.delegate(selector,event,callback);
.on(event,selector,callback);

//to avoid multiple underlying implementations
//you can "map" the old API to use the new API's implementation
//while maintaining the old interface and functionality
live = function(event,callback){
    $(document).on(event,callback);
}
delegate = function(selector,event,callback){
    $(this).on(event,selector,callback);
}

//the new implementation as used by on
on = function(event,selector,callback){
    //implementation
}
于 2012-05-22T11:03:52.343 に答える
1

明確でないいくつかの事柄:

  1. コードの Flash 側を構築しているのは誰ですか? コンポーネントを使用する人、またはコンポーネントをコンパイルして中身を知らない人はいますか?

  2. 聴衆は一般的にどれくらい精通していますか？

  3. コンポーネントを使用して構築されたアプリケーションの一般的な寿命。バージョン ポリシーを明示しましたか?

IMO：（ これは私の意見であり、絶対的な真実ではないことを意味します。このアプローチはLinux開発ではより一般的ですが、たとえばWindowsでは恐ろしい/非一般的です）。

ユーザーがコードを作成している場合は、2 ～ 3 のマイナー バージョン リリースのメタに直行し[Deprecated()]、その後ドロップすることをお勧めします。もちろん、メジャー バージョン リリースにドラッグしないでください。帯域幅がある場合は、古いバージョンのサポートを提供し、場合によってはパッチをリリースすることをお勧めしますが、改善することはより重要です。特定の戦術が役立つ場合があります。たとえば、ユーザーがベータ版製品に触れた場合、変更をより迅速に採用する可能性が高くなります。

聴衆のほとんどが知識が豊富で、コミュニティとのコミュニケーションが良好である場合は、おそらく 1 つのマイナー バージョンで十分でしょう。最悪の場合、互換性のある古いバージョンがほとんど残っていないでしょう。繰り返しますが、古いバージョン用のパッチがあるのは良いことですが、間違った API を使用し続けることで手を縛ることになります。しばらくすると、その API が原因で、ユーザーはあなたのアプリケーションを時代遅れのがらくたと見なすようになり、ユーザーは自分のアプリケーションを使用せざるを得なくなります。むしろ変わります。

マイナー バージョン間の一貫性のみを約束することが非常に重要です。もちろん、いくつかのバージョンの下位互換性を維持できるのは良いことですが、これは要件ではなくボーナスです。表面的には、あなたの製品を使用している他の人々は変更を採用することに消極的かもしれませんが、他のオプションはさらに悪いものです。サポートを提供するには、アプリケーションの平均寿命に適合する妥当な時間が必要です。有用になる前に平均的なアプリケーションを陳腐化させるようなことはありませんが、すべては適度に行われます。

于 2012-05-22T12:28:32.460 に答える