次の方法で共有

拡張可能なコードの書き込み

  • [アーティクル]

X++ およびメタデータ モデルは、ビジネス ソリューションを構築するため強力な基礎を提供します。 デザインの柱の 1 つは、エンジニアがビジネス ドメインに焦点を当てることができるように、できるだけ多くの技術的な問題を自動化することです。 たとえば、ラベル ファイルにすべてのテキスト リソースを配置した場合、心配しなくてもよい 1 つの技術的な問題はテキスト リソースのローカライズです。

拡張性は、別の技術的な問題です。 他のユーザーが安全かつ堅牢で管理可能な方法でソリューションを拡張できるようにします。 既定では、ソリューションの拡張性は高くなっています。 ただし、完全性を保証するために従う必要のある、いくつかのガイドラインがあります。

職責

どの財務と運用環境でも、さまざまなソースからのコンポーネントを含むビジネス ソリューションが実行されています。 通常、各ソリューションにはマイクロソフト、独立系ソフトウェア ベンダー (ISV)、パートナーのコード、さらに内部開発のコードも含まれています。 各コントリビューターは、ソリューションへの自分の貢献と、自分の貢献が他のユーザーの貢献と関わる方法に責任を負っています。

拡張可能コードを作成するとき、ソリューションを操作するよう他のユーザーを招待します。 自分の責任は、他のユーザーを適切なゲストにすることです。 この責任を果たす方法を以下に示します。

  • 信頼性の高い拡張ポイント 拡張ポイントは、拡張担当者のソリューションの土台です。 適切に定義されていて、リリースごと堅牢である必要があります。
  • 並べてカスタマイズを行う : 複数の拡張ユーザーが同じ拡張機能を使用している可能性ポイントする。 1:1 (1 対 1) のやり取りではなく、1: n (1 対多) のやり取りを有効にします。
  • 拡張担当者の行行の行 : すべての担当者は共有目標を達成し、顧客に対して、より共有なソリューションを作成することを目的とします。 拡張ポイントを作成するときは、コントロールを引き渡し、他のユーザーと責任を共有します。 拡張担当者は慎重であり、意図した拡張ポイントを使用しているとみなします。

実績のある原則

既に使用している優れたエンジニアリングの手法がすべて適用されます。 学習したことすべても適用されます。 新しい原則を習得したり、古い手法を忘れる必要はありません。 この記事では、何十年もの間求められ、教えられ続けてきた、ソフトウェア作成者が守るべき 3 つの原則だけ強調します。 これらの原則により、コードが読み取り、管理、テスト、確認、リファクタリングしやすくなるだけでなく、コードを簡単に拡張できるようにもなります。 これらの原則を適用して推奨します。

SOLID を使用してコードを拡張する

SOLID は、コードを簡単に拡張できるようにするために使用できる 5 つの原則の頭字語です。

  • 単一の : クラスとメソッドは、単一の責任を持つ必要があります。また、サイド 効果を伴う必要はありません。 この原則に従うと、パブリックな保護された方法で自動的に作成される拡張ポイントが優れた拡張ポイントになることを保証することができます。

  • オープン/クローズ

    • [拡張用に する] : 拡張子の面をデザインして考慮して、拡張機能のソリューションを開きます。 拡張ポイントが使用可能になったら、管理を担当します。 この責任は、今後の開発に重要な制限を追加します。 多くの場合、需要に応じて拡張に対してソリューションを開くことをお勧めします。 たとえば、パブリック メソッドより内部メソッドを使用したり、保護されたメソッドよりプライベート メソッドを使用したりします。 プロパティを非公開にし、メソッドを非公開または最終保護にすることにより、拡張サーフェイスを制限します。 この方法により、継承または拡張を通じて、ロジックで依存関係を活用できる人はいません。
    • [変更用に ] : それ以上の変更を行わずにロジック サポート拡張機能を作成します。

  • Lis化代入 : 派生クラスは、基本クラスの代わりに使用できる必要があります。 たとえば、この置き換えは、ファクトリを指定する、SysExtension を使用する、および単純なコンストラクト メソッドを使用することにより実行できます。

  • インターフェイスの分離 : 簡単なインターフェイスを作成します。 この原則により、拡張担当者は置き換えの実装を提供します。次の SOLID 原則である依存関係の反転と組み合わせて使用する場合は、特に重要です。

  • 依存関係の変更 : 抽象化ではなく、抽象化に依存します。 この原則により切り離しが可能になり、拡張担当者は、ロジックが依存している抽象化に準拠している具体的なインスタンスを提供できます。

クリーンなコードの記述

クリーンなコードは、記事のように読むことができます。 メソッドの名前は、記事の見出しを提供します。 次にメソッドの本文があり、概要はわずか数行で構成されます。 この概要は、適切な内容を示す名前を持つ他のいくつかのメソッドを呼び出します。 これにより、読み手は、詳細を閲覧し続け、概念に関する情報を見逃すことなくいつでも停止することもできます。

この方法でコードが記述されると、メソッドは短く (多くの場合 5 ～ 10 コード行未満) なります。 さらに、パラメーターの数が少なくなり (通常は 2 未満)、コードの条件およびブロックが常に 1 つのコード行になります。

次に例を示します。

public void processOrder(SalesOrder _salesOrder)
    {
        if (this.approveOrder(_salesOrder))
        {
            this.confirmOrder(_salesOrder);
        }
        else
        {
            this.rejectOrder(_salesOrder);
        }
    }

X++ では、すべての保護されたパブリック メソッドが拡張ポイントです。 クリーンなコードを記述することで、拡張可能コードを自動的に生成します。 前の例では、拡張担当者が、承認、確認、および否認を実装する方法を変更できます。 実装がインラインである場合、コードは拡張できません。

DRY 原則

実装の不整合を防ぐため、ロジックで冗長性を避けてください。 この原則は、拡張可能コードの場合は特に重要です。拡張担当者は、必要な部分をすべて拡張するとは限らないため、意図せずソリューションが壊れたままにする可能性があります。

X++ で拡張可能ソリューションを作成するためのベスト プラクティス

以下のベスト プラクティスは、コードのユーザーがソリューションを拡張できるように、X++ で拡張可能なソリューションを作成するのに役立ちます。

変更の分割

ソリューションを拡張可能にすると、後で拡張ポイントを壊さずに済むことにもなります。 詳細については、重大な変更を参照してください。

外部リソース

次の外部リソースは、クリーンなコードを作成しているかどうかを確認するのに役立ちます。