注
コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する 」フォームに入力し、参加するコミュニティを選択します。
X++ およびメタデータ モデルは、ビジネス ソリューションを構築するため強力な基礎を提供します。 設計の柱の 1 つは、ビジネス ドメインに集中できるように、できるだけ多くの技術的な懸念を自動化することです。 たとえば、すべてのテキスト リソースをラベル ファイルに配置する場合、テキスト リソースのローカライズについて心配する必要はありません。
拡張性は、別の技術的な問題です。 他のユーザーが安全かつ堅牢で管理可能な方法でソリューションを拡張できるようにします。 既定では、ソリューションの拡張性は高くなっています。 ただし、いくつかのガイドラインに従って、完全性を保証してください。
職責
どの財務と運用環境でも、さまざまなソースからのコンポーネントを含むビジネス ソリューションが実行されています。 通常、各ソリューションにはマイクロソフト、独立系ソフトウェア ベンダー (ISV)、パートナーのコード、さらに内部開発のコードも含まれています。 各コントリビューターは、ソリューションへの自分の貢献と、自分の貢献が他のユーザーの貢献と関わる方法に責任を負っています。
拡張可能コードを作成するとき、ソリューションを操作するよう他のユーザーを招待します。 自分の責任は、他の人々を良いゲストにすることです。 この責任を満たす方法を次に示します。
- 信頼性の高い拡張ポイントを作成する: 拡張ポイントは拡張担当者のソリューションの土台部分です。 適切に定義されていて、リリースごと堅牢である必要があります。
- サイド バイ サイド カスタマイズを招待: 複数の拡張担当者が同じ拡張ポイントを使用する場合があることを認識します。 1:1 (1 対 1) のやり取りではなく、1: n (1 対多) のやり取りを有効にします。
- エクステンダーが適切に動作することを信頼 する – すべての責任ある当事者は同じ目標を共有します。顧客に優れた永続的なソリューションを作成します。 拡張ポイントを作成するときは、コントロールを引き渡し、他のユーザーと責任を共有します。 エクステンダーは慎重であり、拡張ポイントを意図したとおりに使用すると仮定します。
実績のある原則
既に使用している優れたエンジニアリングの手法がすべて適用されます。 学習したことすべても適用されます。 新しい原則を習得したり、古い手法を忘れる必要はありません。 この記事では、何十年もの間求められ、教えられてきたソフトウェア職人技の3つの原則について説明します。 これらの原則により、コードが読み取り、管理、テスト、確認、リファクタリングしやすくなるだけでなく、コードを簡単に拡張できるようにもなります。 これらの原則を適用して推奨します。
SOLID を使用してコードを拡張する
SOLID は、コードを簡単に拡張できるようにするために使用できる 5 つの原則の頭字語です。
1 つの責任 – クラスとメソッドには 1 つの責任があり、副作用は必要ありません。 この原則に従うことで、パブリックメソッドと保護されたメソッドで自動的に作成される拡張ポイントが優れた拡張ポイントであることを保証できます。
オープン/クローズ
- 拡張に対してオープン: 拡張サーフェイスをデザインして検討することにより、拡張のソリューションを開きます。 拡張機能ポイントを使用可能にした後は、それを維持する責任があります。 この責任は、今後の開発に重要な制限を追加します。 多くの場合、需要に応じて拡張に対してソリューションを開くことをお勧めします。 たとえば、パブリック メソッドより内部メソッドを使用したり、保護されたメソッドよりプライベート メソッドを使用したりします。 プロパティを非公開にし、メソッドを非公開または最終保護にすることにより、拡張サーフェイスを制限します。 この方法により、継承または拡張を通じて、ロジックに依存することで利益を得ることはできません。
- 変更に対して閉じている – それ以上の変更を必要とせずに、ロジック サポート拡張機能を作成します。
リスコフ置き換え: 派生クラスは、基本クラスの代わりに使用できる必要があります。 たとえば、この置き換えは、ファクトリを指定する、SysExtension を使用する、および単純なコンストラクト メソッドを使用することにより実行できます。
インターフェイスの分離: 簡単なインターフェイスを作成します。 この原則により、拡張担当者は置き換えの実装を提供します。次の SOLID 原則である依存関係の反転と組み合わせて使用する場合は、特に重要です。
依存関係の反転: 具体化ではなく抽象化に依存します。 この原則により切り離しが可能になり、拡張担当者は、ロジックが依存している抽象化に準拠している具体的なインスタンスを提供できます。
クリーンなコードの記述
クリーンなコードは、記事のように読むことができます。 メソッドの名前は、記事の見出しを提供します。 次にメソッドの本文があり、概要はわずか数行で構成されます。 この概要は、適切な内容を示す名前を持つ他のいくつかのメソッドを呼び出します。 これにより、読み手は、詳細を閲覧し続け、概念に関する情報を見逃すことなくいつでも停止することもできます。
このような方法でコードを記述すると、メソッドは短く、多くの場合、コード行が 5 から 10 行未満になります。 さらに、パラメーターの数が少なくなり (通常は 2 未満)、コードの条件およびブロックが常に 1 つのコード行になります。
次に例を示します。
public void processOrder(SalesOrder _salesOrder)
{
if (this.approveOrder(_salesOrder))
{
this.confirmOrder(_salesOrder);
}
else
{
this.rejectOrder(_salesOrder);
}
}
X++ では、すべての保護されたパブリック メソッドが拡張ポイントです。 クリーンなコードを記述することで、拡張可能コードを自動的に生成します。 前の例では、拡張担当者が、承認、確認、および否認を実装する方法を変更できます。 実装がインラインの場合、コードは拡張可能ではありません。
DRY（Don't Repeat Yourself）原則
実装の不整合を防ぐため、ロジックで冗長性を避けてください。 この原則は、拡張可能コードの場合は特に重要です。拡張担当者は、必要な部分をすべて拡張するとは限らないため、意図せずソリューションが壊れたままにする可能性があります。
X++ で拡張可能なソリューションを作成するためのベスト プラクティス
以下のベスト プラクティスは、コードのユーザーがソリューションを拡張できるように、X++ で拡張可能なソリューションを作成するのに役立ちます。
破壊的な変更
ソリューションを拡張可能にすると、後で拡張ポイントを壊さずに済むことにもなります。 詳細については、重大な変更を参照してください。
外部リソース
次の外部リソースは、クリーンなコードを作成しているかどうかを確認するのに役立ちます。