カプセル化で完了したコードからのC ++アドバイス？

Question

Code Completeの「良いカプセル化」のセクションでは、プライベートの実装の詳細を非表示にすることをお勧めします。例はC ++に記載されています。アイデアは、基本的に、クラスレベルであっても、インターフェイスを実装から完全に分離することです。

class Employee {
public:
    ...
    Employee( ... );
    ...

    FullName GetName() const;
    String GetAddress() const;

private:
    EmployeeImplementation *m_implementation;
};

これは本当に時間の使用ですか？これは非効率的に見えるだけでなく（これはどのようなパフォーマンスのペナルティが与えられますか？）、コードのモットー全体（「複雑さの管理」）が逆転したようです。 追加 複雑？

Answer 1

Pimpl Idiomのもう1つの利点は、 アビ. 。見る 実際にはpimpl idiom.

サイズ クラスの一定のままです。これは、インターフェイスをそのままに保ちながら、内部実装を変更できることを意味します。

実装がコンパイルされたフォーム（lib、dllなど）で配布されている場合、いくつかの条件下では、クラスを使用するコードを再コンパイルすることなくライブラリを置き換えることができる場合があります。したがって、パブリックインターフェイスが変更されない限り、コードを完全にスタンドアロンモジュールとして分離します。

他の人が述べたように、それはまた、編集時間を短縮します。これは、場合によっては十分な理由になる可能性があります。

Answer 2

ヘッダーファイルにはパブリックメンバーのみとプライベート実装への単一のポインターのみが含まれているため、カプセル化が増加します。

また、間接レベルの余分なレベルでパフォーマンスを低下させます。

ここでは、「コンピレーション時間の短縮」が重要な問題です。

あなた（あなたの会社）がクラスの唯一のユーザーである場合、このイディオムを使用する理由がないと思います。パフォーマンスが低くなり、とにかくソースコードの毎日（または定期的な）再構築が必要です（クラス間の依存関係に注意する必要があります）。

これは、あなたがクラスの唯一の消費者である場合、編集時間はほとんど無関係であるべきであることを意味します。

ライブラリを配布している場合、ストーリーは完全に異なります。ヘッダーの変更は、あなたが行ったことがクラスのプライベート部分を変更したとしても、あなたが持っているクライアントがあなたの新しいバージョンを使用するために彼らのアプリケーションを再構築する必要があることを意味します。ここでPimpl Idiomを使用すると、変更が動的ライブラリのユーザーには見えないことを意味します。

Answer 3

ポインターを介して余分なレベルの間接を使用すると、追加のキャッシュミスを引き起こし、プログラムを遅くすることができます。 AFAIK、このイディオム（PIMPL）は、編集時間を短縮するために最もよく示唆されます。あなたが持っていると言ってください employee.h ヘッダーは、1つのポインターではなく、クラス内のすべてのフィールドを使用しています。これで、従業員の詳細（フィールドの追加または削除など）を変更するたびに、 employee.h 再コンパイルする必要があります。あなたが持っているのは、で定義されている実装クラスへの単一のポインターである場合 employee.cpp, 、次に employee.cpp 変更するときに再コンパイルする必要があります EmployeeImplementation.

さて、編集時間の短縮は追加費用の価値がありますか？あなただけがそれを決めることができます。

Answer 4

Pimpl Idiomの主な利点（または少なくともそれらの場合）は、編集時間を節約するのではなく、許可すると思います。 ゆるいカップリング, 、つまり、コンポーネント間の依存関係を破る。

他の多くのコンポーネントが使用するインフラストラクチャライブラリを提供するとします。その後、@Zvrbaが示したように、プライベート実装の詳細を変更するたびに、すべてのクライアントが再コンパイルする必要があります。大したことではないかもしれませんが、大規模で複雑なプロジェクトでは、コンポーネント間の統合が複雑なタスクである可能性があります。 PIMPLを使用すると、ライブラリが動的（dll、.so）の場合、クライアントにはアクションは必要ありません。

Answer 5

このイディオムは、貧弱なヘッダーを抽象化するために使用されますが、他にはあまり使用されません。クラスを定義するために必要なタイプが、マクロを漏れ、コンパイルするのに長い時間がかかるヘッダーを含めることを含む場合にのみ使用します。それ以外に、通常は正しいこととは見なされません。とにかく、実装には動的な割り当てと参照セマンティクスが必要なので、インターフェイスにして提供するだけでもあります。 CreateForMyPlatform() CPPファイルに定義がある方法。少なくとも、そのシナリオにスマートポインターを使用できます。