2016-12-13 18 views
1

循環依存性を散らばった大きなC++コードベースでコンパイル時間を改善したい。私は循環的な依存関係を減らすために、主に純粋な抽象的なインターフェースを使用し、プロジェクトをより小さなモジュールに分割できるようにすることに決めました。純粋な抽象クラスと派生型のインスタンス化

ibar.h:

struct IBar { 
    IBar(); 
    virtual ~IBar(); 
    virtual void foo() = 0; 
} 

std::unique_ptr<IBar> createIBar(); 

がbar.cpp:

#include "ibar.h" 

class Bar : IBar { 
    Bar(); 
    virtual ~Bar(); 
    virtual void foo() {<do stuff>;} 
} 

今私のcreateIBar機能はどこかに定義する必要があります。私がbar.cppで定義した場合、ibar.hを使用している人はbar.oをリンクする必要があります。これは避けようとしているものです。だから、私はこのインターフェースを使うだけでクライアントのために働くことができる何らかの種類の工場が必要です。

コードベースでは、インターフェイスの任務を果たすために派生クラスをインスタンス化するランタイム初期化プログラムを作成するパターンを既に採用しています。これは、固定パターンに基づいてイニシャライザ関数を識別するビルドシステムによって行われ、これらはextern int定義によってメインアプリケーションに「リンク」され、アプリケーションの起動時にすべてのインスタンス生成が実行されます。

このパターンを使用して、IBarについて知っているだけのクライアント用のバーを作成するファクトリを作成することができましたが、私が最初に改善しようとしているビルドシステムに余分な義務を課すため、 。第二に、遅い段階で遅延ロードDLLを採用したいと思います。このパターンは効果的にそのDLLを殺します。第三に、これは非常に多くのコンポーネントで実行されるため、しばらくするとファクトリとイニシャライザ呼び出しのリストがかなり大きくなります。

このユースケースを担当できる他の技術はどれですか?

+1

これはあなたに興味があるかもしれません。http://stackoverflow.com/questions/23626803/can-a-factory-somehow-determine-all-possible-classes-by-looking-in-particle/23626894# 23626894 – StoryTeller

答えて

0

(自分自身で回答します)abstract factory patternは、ベースハンドルを持つ派生オブジェクトを作成しています。これは、私が行っているインターフェイス/実装分離作業の中で最も優れていると結論づけました。

StoryTellerによって提案されたcrtp patternは、バーを作成する必要があるすべての場所でバーへのリンク時間依存性を受け入れると、部分を再生することもできます。 Crtpは静的な多態性に役立ちます。静的なcreateBar関数への呼び出しは、通常の多態性では不可能な静的なcreateBar関数にリレーできます。私はこのパターンを使ってリンク時間の依存性を避けることができませんでした。

関連する問題