Идеальное количество классов на ветвь пространства имен

Question

Какое количество классов, по вашему мнению, идеально для одной «ветви» пространства имен?В какой момент можно решить разбить одно пространство имен на несколько?Давайте не будем обсуждать логическую группировку классов (предположим, что они логически сгруппированы правильно), на данный момент я сосредоточен на поддерживаемых и управляемых классах.не поддерживаемое количество классов.

Answer 1

«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

Answer 2

Что касается современных IDE и других инструментов разработки, я бы сказал, что если все классы принадлежат пространству имен, то не существует произвольного числа, по которому вам следует разбить пространство имен только для удобства обслуживания.

Answer 3

Я думаю, что пространство имен должно быть настолько большим, насколько оно должно быть.Если есть логическая причина создать родственное или дочернее пространство имен, сделайте это.Основная причина, по моему мнению, разделения на пространства имен — это упрощение разработки, облегчающее разработчикам навигацию по иерархии пространств имен в поисках того, что им нужно.

Если у вас есть одно пространство имен с множеством типов, и вы чувствуете, что трудно найти определенные из них, рассмотрите возможность их перемещения в другое пространство имен.Я бы использовал дочернее пространство имен, если типы специализируют типы родительского пространства имен, и родственное пространство имен, если типы могут использоваться без исходных типов пространства имен или иметь другую цель.Конечно, все зависит от того, что вы создаете, и целевой аудитории.

Если пространство имен содержит менее 20 типов, его вряд ли стоит разделять.Однако вам следует учитывать распределение пространства имен во время проектирования, чтобы заранее знать, какие типы входят в какие пространства имен.Если вы распределяете пространство имен во время разработки, ожидайте большого количества рефакторинга, поскольку вы определяете, что и где должно быть.

Answer 4

Одна вещь, которая здесь не рассматривается, хотя она в некотором роде связана с точкой зрения Криса, заключается в том, что обучаемость пространства имен связана не только с количеством элементов.

(Кстати, это относится к «пространству имен» в самом широком смысле — класс сам по себе является пространством имен в общем смысле, поскольку он содержит определенные имена, которые в этом контексте означают другое, чем в другом, перечисление — это пространство имен в это чувство тоже).

Допустим, я столкнулся с пространством имен, связанным с XML, с Элемент сорт.Я немного узнаю об этом, и когда я смотрю на Атрибут класс, я вижу некоторое сходство.Когда я затем вижу Инструкция по обработке class, я могу сделать разумное предположение о том, как он работает (и, вероятно, это ошибка дизайна, если я думаю совершенно неправильно; в лучшем случае различия нужно не просто задокументировать, но и объяснить).Я могу предположить, что есть Комментарий класс еще до того, как я его увижу.я пойду искать тебя ТекстНоде class и задаемся вопросом, наследуются ли все они от Узел вместо того, чтобы узнавать о них из документации.Мне интересно, какой из нескольких разумных подходов вы выбрали в отношении своего Ланг класс, а не задаваться вопросом, есть ли он там.

Поскольку все это относится к области, о которой я уже знаю, концептуальная «стоимость» этих семи классов намного, намного меньше, чем если бы эти семь классов были вызваны Овца, Телевидение, ОсеньСайгона, Энуии, Аманда ПалмерсСолоРабота, ДляИскусстваСакеКоэффициент и Из-за процесса.

Это относится к точке зрения Чирса, потому что он говорит, что ради удобства использования нам рекомендуется сократить количество вариантов выбора.Однако, если у нас есть выбор стран в алфавитном порядке, мы сразу просматриваем весь список и мгновенно выбираем ту, которая нам нужна, поэтому совет ограничить выбор неприменим (действительно, несколько вариантов одновременно могут быть и тем, и другим). менее полезно и потенциально оскорбительно).

Если в вашем пространстве имен 200 имен, но вам нужно только Действительно выучите полдюжины, чтобы понять многое, и тогда будет гораздо легче вникать, чем иметь дюжину имен, мало связанных друг с другом.

Answer 5

Я знаю, что вы не хотите обсуждать логическую группировку, однако для разделения вам нужно иметь возможность группировать два разных пространства имен.Я бы начал рассматривать новое пространство имен примерно с 30 классами;однако я бы не стал считать это серьезной проблемой.

Answer 6

Я должен сказать, что нахожу все вышеперечисленное очень удивительным чтением.

Эксперты по юзабилити советуют нам ограничить количество вариантов в меню, чтобы мы могли сразу увидеть все варианты.То же самое относится и к тому, как вы организуете свою работу.

Обычно я ожидаю от 4 до 10 типов в пространстве имен.Экономит много времени на поиске вещей и прокрутке вверх и вниз.Перемещать вещи с помощью resharper так быстро и легко, что я не вижу причин, почему бы этого не сделать.

Answer 7

Еще одна вещь, о которой следует упомянуть, это то, что часто бывает полезно поместить класс, содержащий методы расширения, в его собственное пространство имен, чтобы вы могли включать или отключать эти методы расширения с помощью using директива.Итак, если объект в пространстве имен является статическим классом, содержащим методы расширения, ответ — 1.