Идеальное количество классов на [закрытое] ответвление пространства имен
7 ответов
"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
С современными IDE и другими dev инструментами, я сказал бы что, если все классы принадлежат пространства имен, то нет никакого произвольного числа, в котором необходимо разбить пространство имен только для пригодности для обслуживания.
Я знаю, что Вы не хотите обсуждать логическую группировку, однако делать разделение, необходимо смочь сгруппировать два различных пространства имен. Я начал бы рассматривать новое пространство имен приблизительно в 30 классах; однако я не считал бы это главным беспокойством.
Другая вещь, которая должна упомянутый, состоит в том, что это часто платит для помещения класса, содержащего дополнительные методы в его собственном пространстве имен, так, чтобы можно было включить или отключить те дополнительные методы с a using директива. Таким образом, если вещью в пространстве имен является статический класс, содержащий дополнительные методы, ответ равняется 1.
Я должен сказать, что нахожу все вышеупомянутое очень удивительное чтение.
Эксперты по удобству использования говорят нам сохранять количество выбора в меню к ограниченному количеству, таким образом, мы можем сразу видеть весь выбор. То же относится, как Вы организуете свою работу.
Я обычно ожидал бы 4-10 типов в пространстве имен. Сохраняет такой поиск вокруг для материала и прокрутки вверх и вниз. Это так быстро и легко переместить материал вокруг использования resharper, что я не вижу оснований почему не к.
Я думаю, что пространство имен должно быть столь большим, как это должно быть. Если существует логическая причина создать одноуровневое пространство имен или дочернее пространство имен, то сделайте так. Главная причина, поскольку я вижу его для разделения на пространства имен, состоит в том, чтобы упростить разработку, помогающую разработчикам перемещаться по иерархии пространства имен для нахождения то, в чем они нуждаются.
Если у Вас есть одно пространство имен с большим количеством типов, и Вы чувствуете, что трудно найти определенные, затем рассмотреть перемещение их к другому пространству имен. Я использовал бы дочернее пространство имен, если типы специализируют родительские типы пространства имен и одноуровневое пространство имен, если типы могут использоваться без исходных типов пространства имен или иметь другую цель. Конечно, все это зависит от того, что Вы создаете и целевая аудитория.
Если пространство имен будет иметь меньше чем 20 типов, то это вряд ли будет стоить разделить. Однако необходимо рассмотреть выделение пространства имен во время дизайна так, чтобы Вы знали впереди при разработке, во что типы входят который пространства имен. Если Вы делаете выделение пространства имен во время разработки, ожидаете большой рефакторинг, поскольку Вы определяете то, что должно пойти где.
Одна вещь, которая здесь не рассматривается, хотя она в некотором смысле связана с точкой зрения Криса, заключается в том, что обучаемость пространства имен связана не только с количеством элементов.
(Между прочим, это относится к «пространству имен» в самом широком смысле - класс сам по себе является пространством имен в общем смысле, поскольку он содержит определенные имена, которые в этом контексте означают иное, чем в другом, перечисление - это пространство имен в этом смысле тоже).
Допустим, я столкнулся с пространством имен, связанным с XML, с классом Element . Я немного узнал об этом, и когда я смотрю на класс Attribute , я вижу некоторое сходство. Когда я затем вижу класс ProcessingInstruction , я могу сделать разумное предположение о том, как он работает (и, вероятно, это недостаток дизайна, если я предполагаю совершенно неверно, в лучшем случае различия нужно не просто документировать, но и объяснять) . Я могу догадаться, что есть класс Comment , еще до того, как я его увидел.Я пойду поищу ваш класс TextNode и задаюсь вопросом, наследуются ли все они от Node , вместо того, чтобы узнавать о них из документации. Я буду интересоваться, какой из нескольких разумных подходов вы использовали со своим классом Lang , вместо того, чтобы интересоваться, есть ли он там.
Поскольку все это относится к области, о которой я уже знаю, концептуальная «стоимость» этих семи классов намного, намного меньше, чем если бы семь классов были названы, Sheep , Television , FallOfSaigon , Enuii , AmandaPalmersSoloWork , ForArtsSakeQuotient и DueProcess .
Это относится к точке зрения Чирса, потому что он говорит, что нам рекомендуется для удобства использования уменьшить количество вариантов выбора. Однако, если у нас есть выбор стран в алфавитном порядке, мы сразу же просматриваем весь список и сразу же выбираем ту, которая нам нужна, поэтому совет ограничивать выбор не применяется (действительно, несколько вариантов одновременно могут быть как менее полезно и потенциально оскорбительно).
Если в вашем пространстве имен 200 имен, но вам нужно только действительно выучить полдюжины, чтобы понять все, тогда будет намного проще нащупать, чем иметь дюжину имен, мало связанных друг с другом. разное.