Существует ли такая вещь, как "раздувание классов" - то есть слишком много классов, вызывающих неэффективность?

Question

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

• Item

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

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

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

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

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

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

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

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

• Много классов неэффективно?

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

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

Answer 1

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

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

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

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

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

Answer 2

Много классов неэффективно?

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

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

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

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