4

これは、C++ そのものよりも、C++ アプリケーションをビルドする方法に関する質問です。

グラフィカル アプリケーションとして構想されたアプリケーションを構築していますが、実装の詳細には、ファイルや Web リソースなどからオブジェクトのリストを読み取るなど、インターフェイスを容易にするための大量の抽象的な機能が必要です。この機能を難なく実装する方法を教えてください。しかし、それをテストする良い方法がありません。具体的には、グラフィカル環境の実装を開始しましたが、下位レベルの機能を使用する準備がまだできていません。

また、下位層で実行したいことをかなり構築しましたが、まだテストされていません。このコードはすべて単一のフォルダーにあり、定期的なコミットでバージョン管理システムに保存されます。

私は、C++ で機能的なものを作成するのは比較的初めてで、これまでクラス プロジェクトでしか作業していませんでしたが、さまざまな種類のプログラムを PHP でかなりの数作成しました。

これが PHP プロジェクトである場合、どの機能も簡単にテストできます。

  1. インタラクティブに実装することから始めます
  2. それを小さなファイルにコード化する
  3. 機能を使用したコードを書く
  4. 関数に組み込む
  5. その関数をより大きなコード本体にインポートします。

これは、C++ で同じことを行うには非常に厄介な方法のように思えます。コンパイルされたプログラムで、小さな孤立した問題をどのように解決し、それらをプロジェクトにインポートしますか? 役立つワークフローはありますか。

4

3 に答える 3

2

一般的に言えば、あなたの質問に対する答えは、クラスと単体テストを使用することです。Agile / Extreme Programming をインターネットで検索してください。

アイデアは次のとおりです。

  1. アジャイルのストーリーをすべて実行します (これについては自分で読んでもらいます)
  2. デザインをクラスに分割します
  3. クラスの「仕様」を定義する単体テストを作成する
  4. 空のプレースホルダー関数を記述します。
  5. 単体テストが失敗することを確認してください。
  6. 単体テストが成功するまでコードを書きます。
  7. ステップ 3 に戻り、残りのクラスについて繰り返します。

この方法でコードを作成すると、再利用可能で堅牢なコードが作成されます。

正直なところ、私は個人的に真の TDD (テスト駆動開発) を信じていません -- コードを書いた後に単体テストを書く方が良いと感じています (ユーザーが「AGILE OR DIE」と叫ぶことで破滅の炎が差し迫っているのを感じます)。 !")。

編集:あなたの質問が複数のクラスの実際の構築の嘘に沿っている場合、それは簡単です。一般的に言えば、各クラスは 2 つのファイル (ソース コードとヘッダー ファイル) にカプセル化する必要があります。これらのファイルを (使用する他のすべてのクラスのファイルと共に) 新しいプロジェクトに含めるだけです。クラスを使用する必要がある適切な場所に "xxx.h" を #include し、それらのクラスを使用するコードを記述してビルドします。それでおしまい。

于 2010-11-05T23:18:57.087 に答える
1

これは、あらゆる OO プロジェクトの一般的な戦術になると思います。

最初に主要なコンポーネントを特定し、すべてが何を担当しているのかを完全に理解していることを確認してください。

各コンポーネントのインターフェースを書き出し、それが問題に適合するかどうかを (論理的に) チェックしてください。

各モジュールを実装します。

テストに関する限り、テスター モジュール (スタブ) を作成します。たとえば、実際のコンポーネントによって送信される入力を模倣して、GUI に入力を送信するクラスを作成します。インターフェイスについて明確な考えがあるので、この結果がどのように生成されたかは関係ありません。

システム内のコンポーネントごとにこのプロセスを繰り返してから、それらをまとめます。

それが役に立てば幸い

于 2010-11-05T04:22:03.427 に答える
0

私は現在、同様の状況にあり、機能の断片を実装しています (API を介したファイル I/O、作業の主要部分など)。だから多分私の経験のいくつかが役立つでしょう：

  • すでにコードがある場合は、そのコードを図に描くと役立つ場合があります。ペンと紙、またはそれ以上の UML がここで役に立ちます (ちなみに、既存のクラスをインポートできる優れた UML ツールは Umbrello です)。時々、最後のコミットの後にこの種の「デザイン チェック」を行います。これは、特にクラスを毎日リファクタリングしていた設計段階で、いくつかの微妙な問題を見つけるのに役立ちました。
  • コンポーネントのコードを書いた場合は、それぞれの要件を簡単に定式化できると思います。これらからいくつかのテストを作成できます (たとえば、「UnitCPPLite」を使用)。現在、メイン ファイルにテストがあり、アプリケーションで他の処理が行われる前にテストの実行をトリガーするいくつかのボイラープレート コードがあります (ただし、これはまだ最適ではありません)。
  • 最後に、ComtriS の推奨事項に、ヘッダー ファイルの複数のインクルードを防ぐための "インクルード ガード" (まだ使用していない場合) のアイデアを追加します。したがって、実際には、通常、次のような結果になります。

ソース/CFoo.h:

// class 'CFoo': header file
#ifndef CFOO_H
#define CFOO_H

#include <only_what_you_need_in_declaration_interface>

class CFoo {
    private:
        // class data
    public:
        // constructors, destructors, getters, setters, etc.
        void doWork();
    };
#endif /* CFOO_H */

ソース/CFoo.cpp:

// class 'CFoo': implementation file
#include "CFoo.h"
#include <what_you_need_in_addition_for_internal_workings_of_methods>

// code for other methods...

void CFoo::doWork() {
    // work
}

それが役に立てば幸い。

于 2010-11-14T12:18:29.897 に答える