Pegaにおけるオブジェクト指向開発
Pegaにおけるオブジェクト指向開発
Pegaアセットの設計と再利用を検討するに当たって、まず、オブジェクト指向開発（OOD）の原則について簡単に説明してから、Pega Platform™におけるこれらの原則の活用や、Pega Platformによってどのように原則を活用できるようになるかについて説明していきます。
Robert Martinによると、オブジェクト指向開発は、3つの重要な側面と5つの原則を包含しています。
オブジェクト指向開発の側面
OODの3つの重要な側面は、次のとおりです。
カプセル化
カプセル化は、クラス内部の構造化されたデータオブジェクトの値や状態を隠蔽し、権限のない者がオブジェクトに直接アクセスできないようにするために使用されます。
継承
継承とは、あるオブジェクトが他のオブジェクトの状態、動作、機能を引き継ぐことです。
ポリモーフィズム
ポリモーフィズムによって、エンティティにそのコンテキストに応じてさまざまな意味や使い方を割り当てることができます。 したがって、1つのエンティティを各種アクションの全般カテゴリーとして使用できます。
SOLID開発原則
SOLIDとは、OODの5原則を覚えやすいように表した用語です。 Martinによれば、OODはこの5原則を守って行うべきものです。
Single Responsibility（単一責任）
Open/Closed（開放/閉鎖）
Liskov Substitution（リスコフの置換）
Interface Segregation（インターフェイス分離）
Dependency Inversion（依存性逆転）
単一責任
「単一責任の原則」とは、各モジュールはソフトウェアの機能の単一の部分にのみ責任を持つべきであり、モジュールが責任をカプセル化するという原則です。
単一のルールセットを含むUIKitアプリケーションは、「単一責任」の一例です。
開放/閉鎖
「開放/閉鎖の原則」とは、ソフトウェアのエンティティ（クラス、モジュール、関数など）は、拡張に対しては開かれており、修正に対しては閉じているべきであるという原則です。 エンティティは、そのソースコードを修正しなくても、その動作を拡張できます。
「開放/閉鎖の原則」は、Pegaの拡張性に最も直接的に関連しています。 正しく実装されていれば、別のオブジェクトBに機能が追加されても、このオブジェクトBを使用するオブジェクトAを変更する必要はありません。 この原則に従うことで、新しい要件をサポートする新しいコードが追加されたときに、メンテナンスに集中する波及効果を回避できます。 「開放/閉鎖の原則」の例として、Pega Foundation for HealthcareのPegaHC-Data-Partyクラスが、PegaRULESのData-Partyクラスを拡張していることが挙げられます。
リスコフの置換原則
「リスコフの置換原則」とは、基本クラスによって他のオブジェクトを参照するオブジェクトは、そのクラスがどのように拡張されたかを知る必要がないという原則です。 Pega Platformの例では、クラスがData-Party-PersonまたはData-Party-Orgのいずれであっても、対応とルーティングは同じように動作します。
インターフェイス分離
「インターフェイス分離の法則」（ISP）とは、あるオブジェクトに対して、大きくて複雑な単一のインターフェイスを公開するのではなく、それぞれが特定の目的を果たす複数のインターフェイスを定義する方がよいという原則です。 ISPは、システムを分離し、リファクタリング、変更、再デプロイを容易化することを目的としています。 Pega PlatformにおけるISPの例としては、サービスパッケージやパラメーター化されたデータページなどが挙げられます。 データの伝播も、複数の個別のスカラープロパティではなく、単一のデータインスタンスが渡される場合は、ISPの定義を満たします。
依存性逆転
「依存性逆転の原則」とは、オブジェクトが、依存するオブジェクトの設定や構築を容易にするソフトウェア開発手法のことです。 これは、オブジェクトが依存関係を完全にカプセル化することとは対照的です。 「依存性逆転の原則」は、「リスコフの置換原則」と密接に関連しています。 Pega Platformにおける依存性逆転の例としては、ダイナミッククラス参照（DCR）が挙げられます。 オブジェクトが厳密にルールのPages & Classesタブ内にハードコードされた値を使用してページを作成するのとは異なり、データページはページのpxObjClassプロパティに値を入力するよう求められる場合があります。