11

1 つの名前空間「ブランチ」ごとに理想的なクラス数はいくつだと思いますか? 1 つの名前空間を複数の名前空間に分割することを決定するのはどの時点ですか? クラスの論理的なグループ化については説明しません (論理的に適切にグループ化されていると仮定します)。ここでは、保守可能なクラスと保守できないクラスの数に焦点を当てています。

4

7 に答える 7

27

「42？いや、ダメだ……」

では、プログラミングの腕前を働かせて、Microsoft の意見を見てみましょう。

# IronPython
import System
exported_types = [
  (t.Namespace, t.Name)
  for t in System.Int32().GetType().Assembly.GetExportedTypes()]

import itertools
get_ns = lambda (ns, typename): ns
sorted_exported_types = sorted(exported_types, key=get_ns)
counts_per_ns = dict(
  (ns, len(list(typenames)))
  for ns, typenames
  in itertools.groupby(sorted_exported_types, get_ns))
counts = sorted(counts_per_ns.values())

print 'Min:', counts[0]
print 'Max:', counts[-1]
print 'Avg:', sum(counts) / len(counts)
print 'Med:',
if len(counts) % 2:
  print counts[len(counts) / 2]
else: # ignoring len == 1 case
  print (counts[len(counts) / 2 - 1] + counts[len(counts) / 2]) / 2

これにより、名前空間ごとの型の数に関する次の統計が得られます。

C:\tools\nspop>ipy nspop.py
Min: 1
Max: 173
Avg: 27
Med: 15
于 2008-09-29T12:34:04.400 に答える
8

最新の IDE やその他の開発ツールでは、すべてのクラスが名前空間に属している場合、保守性のためだけに名前空間を分割する任意の数はありません。

于 2008-09-28T17:38:43.943 に答える
3

名前空間は必要なだけ大きくする必要があると思います。兄弟の名前空間または子の名前空間を作成する論理的な理由がある場合は、そうしてください。名前空間に分割する主な理由は、開発を容易にし、開発者が名前空間階層をナビゲートして必要なものを見つけやすくすることです。

多くの型を持つ 1 つの名前空間があり、特定の型を見つけるのが難しいと感じた場合は、それらを別の名前空間に移動することを検討してください。型が親の名前空間の型を特殊化する場合は子の名前空間を使用し、型が元の名前空間の型なしで使用できる場合、または別の目的を持つ場合は兄弟の名前空間を使用します。もちろん、それはすべて、作成するものとターゲット ユーザーによって異なります。

名前空間の型が 20 未満の場合、分割する価値はほとんどありません。ただし、開発時にどの型がどの名前空間に入るかを事前に把握できるように、設計時に名前空間の割り当てを検討する必要があります。開発中に名前空間の割り当てを行う場合は、何をどこに配置するかを決定する際に、多くのリファクタリングが必要になります。

于 2008-09-28T19:09:22.400 に答える
1

ここで取り上げていないことの 1 つは、ある意味では Chris のポイントに関連していますが、名前空間の学習可能性はアイテムの数だけに関連するものではないということです。

(ちなみに、これは最も広い意味での「名前空間」に適用されます。クラス自体は、そのコンテキストでは別の意味を持つ特定の名前を含むという点で、一般的な意味での名前空間です。列挙型は、この感覚も）。

Elementクラスを持つ XML 関連の名前空間に遭遇したとしましょう。これについて少し学び、Attributeクラスを見ると、いくつかの類似点が見えます。その後、ProcessingInstructionクラスを確認すると、それがどのように機能するかについて合理的な推測を行うことができます (完全に間違っていると推測する場合は、おそらく設計上の欠陥です。せいぜい違いを文書化するだけでなく、説明する必要があります)。私はそれを見る前に、 Commentクラスがあると推測できます。私はあなたのTextNodeクラスを探しに行き、ドキュメントからそれらについて学ぶ必要はなく、これらすべてがNodeから継承されているかどうか疑問に思います。あなたがラングで取ったいくつかの合理的なアプローチのうちのどれか疑問に思いますそれがそこにあるかどうか疑問に思うのではなく、クラス。

これらはすべて、私が既に知っているドメインに関連しているため、これら 7 つのクラスの概念的な「コスト」は、 7 つのクラスが呼び出された場合よりもはるかに少なくなります。

これは Chirs の指摘に関連しています。なぜなら、使いやすさのために選択肢の数を抑えるように勧められているからです。ただし、アルファベット順に国を選択できる場合は、すぐにリスト全体を調べて必要な国をすぐに選択するため、選択肢を少なくするというアドバイスは適用されません (実際、一度にいくつかのオプションが両方になる可能性があります)。有用性が低く、侮辱的である可能性があります)。

名前空間に 200 個の名前があるが、その多くを理解するために実際に学ぶ必要があるのは 6 個だけである場合、相互にほとんど関係のない 12 個の名前を持つよりも理解するのがはるかに簡単になります。

于 2010-08-09T21:43:52.513 に答える
0

もう1つ言及する必要があるのは、拡張メソッドを含むクラスを独自の名前空間に配置して、usingディレクティブを使用してこれらの拡張メソッドを有効または無効にできるようにすることです。したがって、名前空間にあるものが拡張メソッドを含む静的クラスである場合、答えは1です。

于 2009-03-26T17:28:32.077 に答える
0

論理的なグループ化について議論したくないことは承知していますが、分割するには、2 つの異なる名前空間をグループ化できる必要があります。私は約 30 個のクラスで新しい名前空間を検討し始めます。しかし、私はそれを大きな懸念事項とは考えていません。

于 2008-09-28T17:39:19.450 に答える