私はプライベートクラスの関数を持たない傾向があることに気づきました。可能であれば、プライベートクラス関数のすべての候補者は、名前のない名前空間に入れて、必要なすべての情報を関数パラメーターとして渡します。なぜそうしているのか、はっきりとした説明はありませんが、少なくとも私にはもっと自然に見えます。結果として、ヘッダーファイルで公開する内部の詳細を少なくする必要があります。
あなたの意見は何ですか-それは正しい習慣ですか?
私はプライベートクラスの関数を持たない傾向があることに気づきました。可能であれば、プライベートクラス関数のすべての候補者は、名前のない名前空間に入れて、必要なすべての情報を関数パラメーターとして渡します。なぜそうしているのか、はっきりとした説明はありませんが、少なくとも私にはもっと自然に見えます。結果として、ヘッダーファイルで公開する内部の詳細を少なくする必要があります。
あなたの意見は何ですか-それは正しい習慣ですか?
私が通常作業している中規模のプロジェクト(200万行を超えるコード)では、可能であればプライベートクラスの関数を禁止します。その理由は、プライベートクラス関数はプライベートですが、ヘッダーファイルに表示されているためです。これは、とにかく署名(またはコメント)を変更した場合、数分(またはプロジェクトによっては数時間)かかる完全な再コンパイルで報われることがあることを意味します。
ただそれにノーと言って、cppファイルでプライベートなものを隠してください。
大規模なc++プロジェクトを最初からやり直す場合は、PIMPL Idiom(http://c2.com/cgi/wiki?PimplIdiom )を適用して、さらにプライベートな詳細をcppファイルに移動します。
私は過去にこれをしました、そしてそれはいつもひどく終わりました。おそらく参照によってプライベートメンバーにアクセスする必要があるため(または複雑なパラメーターリストになってしまうため)、クラスオブジェクトを関数に渡すことはできません。そのため、パブリッククラスメソッドを呼び出すことはできません。また、同じ理由で仮想関数を呼び出すことはできません。私は(経験に基づいて)これは悪い考えだと強く信じています。
結論:これは、実装「モジュール」がクラスへの特別なアクセス権を持っている場合に機能する可能性のある種類のアイデアのように聞こえますが、C++の場合はそうではありません。
基本的には、問題の関数がクラスの一部として本当に意味があるかどうかという問題になります。クラスの詳細をヘッダーから除外することが唯一の目的である場合は、代わりにpimplイディオムを使用することを検討します。
これは良い習慣だと思います。多くの場合、補助構造とデータ型も非表示にするという利点があり、再構築の頻度とサイズが削減されます。また、他の場所で役立つことが判明した場合に、関数を別のモジュールに分割しやすくします。