Есть ли такая вещь, как «раздувание классов» - то есть слишком много классов, вызывающих неэффективность? - PullRequest
0 голосов
/ 21 сентября 2018

Например, давайте рассмотрим, у меня есть следующие классы:

  • Item

  • ItemProperty, которые будут включать такие объекты, как Colour и Size.Есть свойство-отношение класса Item, в котором перечислены все объекты ItemProperty, применимые к этому элементу (т. Е. Для одного элемента вам может потребоваться указать цвет, а для другого вам может потребоваться указать размер).

  • ItemPropertyOption будет включать такие объекты, как Red, Green (для Colour) и Big, Small (для Size).

Тогда объект Item будет относиться к ItemProperty, тогда как объект ItemChoice будет относиться к ItemPropertyOptionItemProperty, на который ссылается ItemPropertyOption, может бытьВывод).

Причина этого в том, чтобы я мог использовать запросы гораздо эффективнее.т.е. дайте мне все варианты предметов, которые Red.Это также позволило бы мне использовать панель Parse Dashboard для быстрого добавления элементов на сайт, так как я мог легко указать больше ItemProperty s и ItemPropertyOption s, вместо того, чтобы добавлять их в кодовую базу.

ЭтоЭто всего лишь небольшой пример, и есть еще много случаев, когда я хотел бы использовать классы, чтобы «опции» для различных раскрывающихся списков в формах были в базе данных и могли быть легко добавлены и отредактированы мной, а не жестко закодированы.

1) Я, вероятно, сделаю это аналогичным образом для более 5 аналогичных типов структур классов

2) могут быть сотни вложенных свойств, к которым я хочу получить доступ через'обратный запрос'

Итак, я могу подумать о 2 потенциальных причинах неэффективности и хотел бы знать, если они основаны:

  • Неужели наличие множества классов неэффективно?

  • Неэффективны ли обратные запросы к вложенным классам?

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

Ответы [ 2 ]

0 голосов
/ 24 сентября 2018

Работа по проектированию состоит в том, чтобы представить в описаниях объектов правды о мире, которые соответствуют требованиям системы.В мире «предметов» ОП это факт, что предметы имеют цвет, и это актуально, потому что пользователи заботятся о цвете предмета.Вы бы назвали систему неэффективной, только если она потребляет вычислительные ресурсы, которые ей не нужны .

Итак, для чего-то вроде конфигуратора, тот факт, что у нас есть элементы, ито, что эти элементы имеют свойства, а эти свойства имеют перечисляемый набор возможных значений, звучит как совершенно рациональный дизайн.

Является ли он неэффективным или «раздутым»?Единственное место, в котором я бы усомнился, это явное утверждение, что у предметов есть свойства.Конечно, это так, но это в корне верно для объектов javascript и объектов синтаксического анализа.

Другими словами, вы можете иметь возможность обойтись только с item и несколькими разновидностями propertyOptions: например, Item имеет атрибут с именем "colorProperty«это указатель на экземпляр« ColorProperty »(экземпляры которого имеют свойство name, например« red »,« green »и т. д. и могут описывать другие соответствующие факты, например, более точное описание в форме RGB).

Нет ничего плохого в том, что многие классы представляют соответствующую истину.Сделай это первым.Вы могли бы эмпирически обнаружить, что ваш дизайн слишком ресурсоемкий (я сомневаюсь, что вы будете в этом случае), и в этот момент мы начнем искать читы, которые будут как-то более стройными.Но сначала делай правильно, а потом обманывай, только если надо.

0 голосов
/ 21 сентября 2018

Неужели неэффективно иметь много классов?

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

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

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

Возможно, вы могли бы потратить некоторое время на размышления о сходстве между этими случаями и придуматьединый набор более гибких классов, которые вы можете использовать во всех этих случаях.Написание общего кода сложнее, чем написание очень конкретного кода, но если вы хорошо поработаете, вы много раз окупите дополнительные усилия за счет повторного использования.

...