5

現在、コードをより良い方法で整理しようとしています。

そのために名前空間を使用し、コンポーネントごとにクラスをグループ化し、それぞれが定義済みの役割といくつかのインターフェイス (実際には抽象クラス) を持っています。

特にコンポーネント全体を書き直す必要があり、他のコンポーネントにほとんど影響を与えずに書き直さなければならなかった場合は特にそうでした。（クラスとメソッドが混在していると、もっと大変だったと思います）

それでも、100% 満足しているわけではありません。特に、インターフェイス、コンポーネントの公開面、およびその背後にある実装をより適切に分離したいと考えています。コンポーネント自体の「インターフェース」はもっと明確であるべきだと思います。つまり、新参者は、どのインターフェースを実装する必要があるのか​​、どのインターフェースを使用できるのか、何が実装の一部なのかを簡単に理解できるはずです。

すぐに、最大 5 人の開発者が関与するより大きなプロジェクトを開始する予定です。

それで、あなたはどうですか？どのようにしますか？コードをどのように整理しますか?

4

5 に答える 5

4

2つの一般的なアプローチがあります。

パブリックインターフェイスとは別に、いくつかのヘルパー関数のみが必要な場合は、実装ファイルの名前のない名前空間にそれらを配置するだけです。

// header:

class MyClass {
// interface etc.
};

// source file:

namespace {
    void someHelper() {}
}

// ... MyClass implementation

メンバー関数を非表示にしたい場合は、PIMPLイディオムの使用を検討してください。

class MyClassImpl; // forward declaration

class MyClass {
public:
    // public interface
private:
    MyClassImpl* pimpl;
};

MyClassImpl機能を実装MyClassし、パブリックインターフェイスへの呼び出しをプライベート実装に転送します。

于 2010-01-21T19:46:04.587 に答える
4

特に、インターフェイス、コンポーネントの公開面、およびその背後にある実装をより適切に分離したいと考えています。

あなたが探しているのはFacadeパターンだと思います：

ファサードは、クラス ライブラリなどのより大きなコード本体への単純化されたインターフェイスを提供するオブジェクトです。-- ウィキペディア

クラスに複雑な相互作用がある場合は、MediatorとBuilderのパターンを確認することもできます。

Pimplのイディオム (別名コンパイラ ファイアウォール) は、実装の詳細を隠してビルド時間を短縮するのにも役立ちます。ポリモーフィズムが必要ない場合は、インターフェイス クラス + ファクトリよりも Pimpl を使用することを好みます。ただし使いすぎには注意。通常はスタックに割り当てられる軽量型 (3D ポイントや複素数など) には Pimpl を使用しないでください。ユーザーから隠したい他のクラス/ライブラリに依存する、より大きくて長寿命のクラスに使用します。

大規模なプロジェクトでは、単純な前方宣言で十分な場合は、ヘッダー ファイルで #include ディレクティブを使用しないことが重要です。絶対に必要な場合にのみ、ヘッダー ファイルに #include ディレクティブを配置します (実装ファイルに #include を配置することをお勧めします)。正しく行われれば、適切な #include 規律により、コンパイル時間が大幅に短縮されます。Pimpl のイディオムは、#includes をヘッダー ファイルから対応する実装ファイルに移動するのに役立ちます。

クラス/関数の首尾一貫したコレクションを独自の名前空間にまとめて、ソース ツリーのサブディレクトリに配置できます (サブディレクトリは、ライブラリの名前空間と同じ名前にする必要があります)。次に、そのパッケージの静的ライブラリ サブプロジェクト/makefile を作成し、それをメイン アプリケーションにリンクできます。これは、UML 用語で「パッケージ」と見なすものです。理想的なパッケージでは、クラスは互いに密接に関連していますが、パッケージ外のクラスとは緩やかに関連しています。パッケージの依存関係図を作成して、循環的な依存関係がないことを確認すると便利です。

于 2010-01-22T00:01:00.527 に答える
1

大規模な C++ ソフトウェア設計の提案のいくつかが役に立つかもしれません。これは少し古い (1996 年に発行された) ものですが、「単一のヘッダー ファイルが変更されたときに世界を再コンパイルする」問題を最小限に抑えるためのコードの構造化に関する指針があり、依然として価値があります。

于 2010-01-21T20:57:10.033 に答える
0

Herb Sutter の「What's In a Class? - The Interface Principle」に関する記事では、多くの人がインターフェイスを設計するときに思いつかないアイデアを紹介しています。少し古い (1998 年) ですが、役に立つ内容が含まれています。

于 2010-01-21T21:46:31.787 に答える
-6

最初に変数を宣言します。これも同様に、1つの文字列宣言で使用できます。

 char Name[100],Name2[100],Name3[100];
 using namespace std;
int main(){

 }

また、プログラムから使用できるコードが長い場合は、それを新しい関数にします。そのようです。

void Return(char Word[100]){
cout<<Word; 
cin.ignore();    
} 
int main(){ 
Return("Hello");
}

そして、ヘッダーファイルに入れて、Dev-C ++#include"Resource.h"のようにリンクする外部関数と宣言をお勧めします。

于 2010-01-21T21:20:05.700 に答える