チェーン・オブ・コマンドは、F&Oカスタマイズのデフォルトパターンになりました。オーバーレイアプローチは持続不可能だったため - すべてのOne Versionアップデートで何かが壊れ、パートナーはアップグレード予算を使って、設計で前向き互換性があったはずのカスタマイズを修復するのに費やしていました。CoCは、拡張機能がnext()でベースメソッドをラップし、全くオーバーレイダンスをスキップできるようにします。
その仕組みを読むのに1分かかる。3つの失敗モードが生産で頻繁に発生し、記録される。
誤解1：拡張時にnext()を忘れる
CoCに慣れていないチームは、このような検証拡張を書くことがよくある：
[ExtensionOf(tableStr(SalesTable))]
final class SalesTableExt_Extension
{
public boolean validateWrite()
{
if (this.CustomCheck == NoYes::No)
{
return checkFailed("Custom check failed");
}
return true;
}
}
バグ：なしnext validateWrite() を呼び出す。基本メソッドは実行されないため、すべての在庫検証が静かに無効になる。カスタムチェックパスのみをテストするユニットテストはパスする。不足している基本検証は、基本が拒否するはずのデータが本番に到達するまで現れない。
ロジックを追加するのではなく置き換える意図がある場合、まず next() を呼び出し、結果を組み合わせる：
public boolean validateWrite()
{
boolean ret = next validateWrite();
if (ret && this.CustomCheck == NoYes::No)
{
ret = checkFailed("Custom check failed");
}
return ret;
}
スキップしていますnext()は時には正当です - しかし意図的に、コメント付きで、レビューされるべきです。意図せずスキップすると、静かなデータ整合性バグが潜んでいます
誤解2：間違ったライフサイクルフックを選ぶ
FormDataSource.init()はレコードが読み込まれる前に実行されます。拡張コードが読み込むthis.cursor() またはレコードコンテキストが記録されると例外が発生するか、予測不可能な動作をします。ダイナミックフィルターを配信しているチームは、それが最初に見つかったフックにロジックを配置するため、空のデータセットを持つユーザーがフォームを開いた最初のときにクラッシュが発生することがあります。init()
フォームレベルのライフサイクルフックはそれぞれ目的があります：
-
init()- フォームレベルのセットアップ、まだデータがない -
executeQuery()- クエリが構築された後、フェッチの前に -
active()- データソース上で記録がアクティブになった後に - イベント前後のハンドラとして
executeQuery- クエリを変更する最もクリーンな方法として基底を上書きせずに
パラメータテーブルから動的なフィルタリングを行う場合、executeQueryのイベント前ハンドラを使用して、イベント引数を通じて利用可能なデータコンテキストでクエリの範囲を変更できます。クラッシュなし、基底メソッドの上書きなし、脆い下游の結合なし。
陷陥3：プライベートまたは保護メンバーにアクセスしようとする
CoC拡張機能は基底クラスのプライベートまたは保護メンバーにアクセスできません。オーバーレイ時代のF&Oから移行してきた開発者は最初にこの問題に直面します：
[ExtensionOf(classStr(SalesLineType))]
final class SalesLineTypeExt_Extension
{
public boolean checkPrice()
{
// Compile error: _commonPricing is protected
return this._commonPricing.checkMyThing();
}
}
マイクロソフトの拡張機能フレームワークドキュメントには4つのオプションが記載されています
- フック可能な基本メソッド - 私的有効な行為が公開メソッドを通じて表面化している場合、そのメソッドを呼び出す.
- 兄弟クラスアクセス - 偶然、公開クラスが必要なものを十分に公開することがある.
- データをargsを通じて公開するメソッド上のイベントハンドラ - 最もクリーンなパス.
- LCS問題検索を通じてアクセスを要求 - Microsoftは、連続するOne Versionリリースにおけるパートナーの要請に応じて多くのメンバーを開放しました。
反射を求めるのは間違いです。次のコンパイルでメンバーのレイアウトが変わるまで動作しますが、それ以降はオーバーレイレベルの脆弱性に戻ってしまいます。
静かな拡張機能のデバッグ
最イライラするCoCの失敗は、コンパイルされ、デプロイされるが、実行時には何もしない拡張機能です。機能しているF&Oコードベースのレビューで現れる根本原因：
-
[ExtensionOf]属性が間違ったターゲットを指している -formStr()/tableStr()/classStr()のタイプミス. - 拡張機能クラスが
finalではない - CoCに必要です。 - メソッドのシグネチャが完全に一致しません - パラメータの型が一致しない場合は無視されます.
- 拡張を含むモデルはターゲット環境のモデルリストにありません.
最初の診断手順：メソッドの上部で info("hit") を削除し、再コンパイルし、シナリオを実行し、Infolog を確認します。何も表示されない場合、上記のいずれかが間違っています.
コードレビューは保険として
健全なF&Oコードベースを運用しているチームは、CoC拡張機能に対してPR時のチェックリストを使用します：next()が正しく呼ばれているか、適切なライフサイクルフックが選択されているか、プライベートメンバーアクセスの試みがないか、SysTestによるユニットテストのカバレッジがあるか。PRごとに15分の時間は、One Versionアップデートが週末の停電に変わるのを防ぐ保険政策です。