私は、私の（必要に応じて難解な）プログラミング言語用のC++でインタープリターを開発してきました。私が気付いた主なことの 1 つ: 私は柔軟な概念から始めており、コーディングを進めれば進めるほど (トークナイザー -> パーサー -> インタープリター)、システム全体の柔軟性が低下します。
例:include最初は関数を実装していませんでしたが、インタープリターはすでに稼働していました。実装するのは非常に困難で、後で「パッチを当てる」ようなものでした。私のシステムはすぐに柔軟性を失いました。
保管が必要な場合
C++ プロジェクトは、開発中に可能な限り柔軟かつ拡張可能
その場合、製品の仕様がなく、本当の目標がなく、完成品を定義する方法がありません。
商用製品の場合、これは最悪の状況です。ある有名なブロガー (誰だったか思い出せません) の言葉を言い換えると、「何をしないかを定義するまで、製品を手に入れることはできません」。
個人的なプロジェクトでは、これは問題にならないかもしれません。経験に基づいて書き留め、将来の参考のために覚えておいてください。リファクタリングして次に進みます。
コーディングを開始する前に、プロジェクトの構造を定義します。主な目標を概説し、それをどのように達成できるかを考えてください。
ヘッダーをコーディングします。
この一連のインターフェースを使用してすべての機能を実装できるかどうかを調べます
いいえの場合 -> (2) に戻る
はいの場合 -> コード .cpp ファイル
楽しみ。
もちろん、これは本当に大規模なプロジェクトには当てはまりません。ただし、設計がモジュール式の場合、プロジェクトを別々の部分に分割しても問題はありません。
進化 (リファクタリング) を恐れないでください。
テーマに合うクラスが多い場合は、共通の基底クラスを作成してください。
データ メンバーをハード コーディングする代わりに、抽象基本クラスへのポインターを使用します。
たとえば、std::ifstreamuseを使用する代わりにstd::istream.
私のプロジェクトでは、読み書き用の抽象クラスがあります。読み取りと書き込みをサポートするクラスは、これらのインターフェイスを使用します。コードを変更せずに、特殊なリーダーをこれらのクラスに渡すことができます。データベース リーダーは基本の Reader クラスから継承されるため、リーダーが使用される場所ならどこでも使用できます。