POCO POCO C++ライブラリ（POCOは「Portable Components」の略）は、C++でのネットワーク中心の移植性のあるアプリケーションの開発を簡素化・加速する、オープンソースのC++クラスライブラリのコレクションです。これらのライブラリは、HTTP/HTTPSクライアントとサーバーから、XML解析、データ暗号化、スレッドサポートまで、豊富な機能を提供しています。
私たちは15年以上にわたりPOCOライブラリに依存して、CppDependがよく実装されたプロジェクトを正確に評価するかどうかを検証してきました。したがって、この評価はライブラリとの一時的な出会いからではなく、過去15年間の多くのバージョンの徹底的な分析から導かれています。
POCOソースコードのコードスニペットを見てみましょう：
このメソッド実装の特徴は次のとおりです：
- パラメータが少ない。
- アサーションを使用して入力が有効かどうかをチェックしている。
- 変数名がわかりやすい。
- メソッドが短い。
- 本体内に不要なコメントがなく、コードは自己説明的です。
- 関数本体が適切にインデントされている。
- 適切な場所でSTLが使われている。
POCOのソースコードを深く掘り下げると、同じベストプラクティスルールが各関数に適用されているため、その実装の一貫性を容易に観察できます。ソースコードを探索すると、POCOはC++初心者にも親しみやすいことがわかります。具体的には、POCOには以下の特徴があります：
- 過剰に設計されておらず、その実装を理解するために高度なC++スキルを持っている必要はありません。
- エンドユーザーに提供されるpublicクラスは、整理されており、簡単に利用できます。
- 設計はモジュラーで、ライブラリはいくつかのプロジェクトに分割され、それぞれが特定のニーズに対応しています。
- ライブラリの高度な利用を求める人にとって、特定のクラスの動作の拡張、カスタマイズ、変更は驚くほど簡単です。
この記事では、その設計のいくつかの重要な側面に焦点を当てます：
抽象性 vs 不安定性
Robert C. Martinは、その設計のサブシステム間の相互依存の観点から、オブジェクト指向設計の品質を測定するために使用できる一連のメトリクスについての興味深い記事を書きました。
モジュール間の相互依存について、彼は記事で次のように述べています：
設計を硬直的で、脆弱で、再利用しにくくするのは何か。それは、その設計内のサブシステムの相互依存です。設計は、容易に変更できない場合に硬直的です。このような硬直性は、強く相互依存したソフトウェアへの単一の変更が、依存するモジュールでの変更の連鎖を始めるという事実に起因します。その変更の連鎖の範囲を設計者や保守者が予測できない場合、変更の影響を見積もることができません。これにより、変更のコストの見積もりが不可能になります。このような予測不可能性に直面したマネージャーは、変更を承認することに消極的になります。こうして設計は硬直的になります。
そして硬直性と戦うために、彼は求心性結合、遠心性結合、抽象性、不安定性、「主系列からの距離」、「抽象性 vs 不安定性」グラフなどのメトリクスを導入しました。
「抽象性 vs 不安定性」グラフは、保守と進化が困難なプロジェクトを特定するのに役立ちます。POCOライブラリの「抽象性 vs 不安定性」グラフは次のとおりです：
このグラフの背後にある考え方は、コード要素が広く使用されるほど、より抽象的であるべきだということです。言い換えれば、実装に過度に依存することを避け、代わりに抽象化に依存すべきです。広く使用されるコード要素とは、プログラムの他のプロジェクトから大量に使用されるプロジェクト（ただし、この考えはパッケージや型にも適用できます）を指します。
コードベース全体で広く使用される具象型を持つことは良いアイデアではありません。これは、実装の変更がプログラムの大部分に影響を与える可能性がある「苦痛の領域」をプログラムに作り出します。そして、実装は抽象化よりも頻繁に進化することが知られています。
上図の主系列線（点線）は、抽象性と不安定性がどうバランスされるべきかを示しています。安定したコンポーネントは左側に位置します。主系列を確認すると、そのようなコンポーネントは望ましい線に近づくためには非常に抽象的であるべきことがわかります。一方、その抽象化の度合いが低い場合、「苦痛の領域」と呼ばれるエリアに位置します。
Foundationプロジェクトのみが苦痛の領域内にありますが、これは正常です。他のプロジェクトから広く使用されており、主に抽象的でないユーティリティクラスを含んでいるためです。
型の凝集度
単一責任の原則は、クラスは変更する理由を1つだけ持つべきであると述べています。そのようなクラスは凝集していると言われます。高いLCOM値は一般に凝集度の低いクラスを示します。LCOMにはいくつかのメトリクスがあります。LCOMは[0-1]の範囲の値を取ります。LCOM HS（HSはHenderson-Sellersの略）は[0-2]の範囲の値を取ります。なお、LCOM HSメトリクスは、凝集していない型を検出するのにより効率的と見なされることが多いです。1を超えるLCOM HS値は警告と見なすべきです。
凝集していないと見なされる型はわずか1%です。
この記事では、POCOの設計の一端を簡単に紹介しました。今後の記事では、その設計と実装をより詳細に探り、このライブラリがよく実装されたオープンソースC++ライブラリの1つとして際立つ理由を理解します。