C++ で見られるものと同様のクラス定義と実装の C# の概念はありますか?
私はクラス定義をシンプルに保つために、すべてではないにしてもほとんどの実装の詳細を削除することを好みます (ご存じのようにいくつかの要因に依存しますが、一般的にはほとんどのメンバー実装の詳細をクラス定義の外に残す方向に進んでいます)。これには、クラスとその機能を俯瞰できるという利点があります。
ただし、C# では、宣言の時点でメンバー関数を定義する必要があるようです。これを回避したり、何らかの方法で回避したりできますか?
C# の見習い期間中、これは私を悩ませている側面の 1 つです。クラス、特に複雑なものは、ますます読みにくくなります。
これは実際には、一歩下がって全体像を見る必要がある場合です。Visual Studioには、アウトライン、＃regions、クラスビュー、クラス図、コード定義ウィンドウなど、コードの記述と操作に役立つツールが多数あります。
C＃はC ++ではありません。そうしようとすると、自分自身につまずいて、他の誰もあなたのコードを読むことができなくなります。
Visual Studioツールの使用法を学ぶのに費やした日は、生産性の面で何度も投資を回収し、C++のやり方でこれまでどのように生きてきたのかすぐに不思議に思うでしょう。
私は長い間、自分のコードを単純なテキストファイルと見なすことをやめました。私はコードを有機的なものと見なしており、機能豊富なIDEに依存できるようにすることで、抽象化のレベルをより簡単に上下に移動でき、生産性を際限なく向上させることができます。それは個人的な特徴かもしれないし、おそらくそれはすべての人のためではないと思います。私は非常に「視覚的な」心を持っており、写真で物事を見ることができるときに最もよく働きます。
とは言うものの、賢いIDEは貧弱なスタイルの言い訳にはなりません。スマートIDEを必要としない「クリーンなコード」を作成するためのベストプラクティスがあります。クリーンなコードの原則の1つは、何かの定義をその使用に近づけることであり、それを拡張して宣言と定義をカバーできると思います。個人的には、宣言と定義を分離すると、コードがわかりにくくなると思います。理解しにくいモンスタークラスを取得していることに気付いた場合、それは単一責任の原則に違反していることを示している可能性があります。
C / C ++で定義と宣言を分離する理由は、C ++がシングルパスコンパイラを使用しているためです。C＃とその2パスコンパイラとは異なり、前方参照は後で解決できません。宣言の順序に関係なく、参照を喜んで見つけることができます。この違いは、コンパイラの設計哲学の違いに起因します。C/ C ++は各ソースファイルをコンパイルの単位と見なしますが、C＃ではプロジェクト全体がコンパイルの単位と見なされます。C / C ++の方法で作業することに慣れている場合、宣言と定義を分離することはスタイルの望ましい要素のように見えるかもしれませんが、宣言と使用（またはこの場合は宣言と定義）を維持することで、むしろ、読みやすさを低下させます。私は2001年にC＃を使い始めるまで、私自身Cプログラマーでした。私は常にCが大好きで、それが「蜂の膝」であると考えていました。最近、C / C ++コードを読んだとき、それは絶対に恐ろしいように見え、私はできると思います。私たちはそのように働くことに我慢していたと信じています。それはすべてあなたが慣れていることの問題だと私は思います。
Visual Studio を使用している場合は、クラス ビューを利用できます。ソース コード エディターの展開/折りたたみ機能を使用することもできます。
ツールが役に立たないというありそうもないケースでは、クラスを要約する簡単なユーティリティをいつでも作成できます。
クラスがコンパイルされている場合は、Reflector を使用してクラスを表示することもできます。
いいえ、C/C++ で見られるような実装とヘッダー ファイルの概念は C# にはありません。これに最も近いのはインターフェイスを使用することですが、インターフェイスはクラスのパブリック メンバーしか定義できません。そうすると、クラスとインターフェースの 1 対 1 のマッピングになってしまいますが、これは実際にはインターフェースの使用方法の意図ではありません。
インターフェイスを定義します。
次に、優れたコード支援ツールを使用してインターフェイスを自動的に実装できると便利です。
クラスごとにインターフェースを定義して実装することで、同様の結果を得ることができます。
インターフェイスを参照しているようです。C# では、すべてのメンバー関数をインターフェイスで定義してから、それらを別のクラスに実装できます。
C# では、部分クラスと部分メンバーである程度偽装できますが、前方宣言とプロトタイプは、新しい言語ではドードー鳥のようになります。クラス ビュー、クラス ダイアグラム、Intellisense などはすべて、これらの「機能」の潜在的な必要性を取り除くのに役立ちます。
クラスが読みにくい、または理解しにくいとわかった場合、それは多くの場合、そのクラスがやりすぎていることを示しています。C++ の宣言と定義の分離を再現しようとする代わりに、問題のあるクラスをいくつかのクラスにリファクタリングして、各クラスの責任を軽減することを検討してください。
可能または望ましい場合はいつでも、以前の応答を使用してインターフェイスを定義します。しかし、それは必ずしも適切ではありません。
あるいは、いくつかの静的コード検査ツールを使用して、この「問題」を回避できます。Resharper の「ファイル構造」ウィンドウは、必要なものを正確に提供します。Visual Studio の組み込みの「クラス ビュー」を使用することもできます。しかし、私は前者を好みます。
あなたが言及していると思われるプロトタイピングは、C# には実際には存在しません。他の人が提案したようにインターフェイスを定義すると、メソッドの宣言を収集するポイントが得られますが、それはプロトタイプと同じではなく、実装クラスを読みやすくするのに役立つかどうかはわかりません.
C# は C++ ではないため、おそらく C++ として扱うべきではありません。
これをより C++ 風にするための 2 つの解決策があります。
partialクラス定義で修飾子を使用して、複数のファイルにまたがるクラスにそのインターフェイスを実装します編集:
// File: ICppLikeInterface.cs
public interface ICppLikeInterface
{
...
}
// File: CppLikeImplementation1.cs
public partial class CppLikeImplementation : ICppLikeInterface
{
...
}
// File: CppLikeImplementation2.cs
public partial class CppLikeImplementation : ICppLikeInterface
{
...
}
インターフェイスをヘッダー ファイルに分離する C++ の方法は、ほとんどの場合 (私が思うに)、C が作成されたときの初期の設計上の決定によるもので、「昔」に高速でインクリメンタルなコンパイルを可能にするためでした。スモールトーク。これは、最近のハードウェアで数万行が数秒以内にコンパイルされる C# (または Java) の問題ではありません (C++ はまだそうではありません)。
クラスが成長し続け、読みにくくなっているという意味がわからない。クラスのメンバーのビューのようなヘッダー ファイルが必要ですか? もしそうなら、ジョンが提案したように、実装を折りたたんで見る必要がないようにすることはできませんか?
すべてのクラスに特定のものを実装させたくない場合は、おそらくインターフェースが最適です（他の人が言っているように）。
しかし、余談ですが、プログラムを作成するにつれてクラス自体がますます複雑になるとしたら、それは言語の問題というよりは設計上の問題ではないでしょうか? クラスは 1 つの責任を持つべきであり、プログラムが成長するにつれてますます多くの責任を負うべきではなく、ソフトウェアの開発を続けるにつれて、クラスの数と使用されるクラスの年齢が増加し、より複雑になるべきだと思いますか?