Сколько объектов слишком много?

Ответ 1

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

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

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

Управление крупным программным проектом - это то, что нужно раскалывать вещи на управляемые части и правильно маркировать их. Если вы это сделаете, количество типов становится менее важным в моем опыте.

Ответ 2

В тот момент, когда вы задаетесь вопросом: "Почему, черт возьми, это объект?"

Недавно у меня был класс "BetForgetter", который я реорганизовал в 2 строки кода в другом классе.

Ответ 3

Это возможно, симптом другой проблемы.

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

PS-Я предполагаю, что вы имели в виду "классы", когда говорили "объекты".

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

Я бы сказал, что вам, вероятно, следует больше беспокоиться о том, что у вас слишком мало объектов/классов. SRP - это то, что стоит соблюдать, поскольку оно обычно приводит к более чистым и понятным кодам.

Ответ 8

Я думаю, что невозможно ответить на ваш вопрос, не зная о вашей проблеме.

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

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

Ответ 9

У вас никогда их не будет, спросите любого достойного Java-программиста.

Ответ 10

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

Ответ 11

Как долго длится строка? (в два раза больше от середины до конца, но это рядом с точкой)

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

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

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

Аналогично, если у вас есть один огромный класс, который содержит много разрозненных функций, то у вас слишком мало классов.

Если у вас есть классы, которые делают то же самое или реплицируют то, что уже делают другие классы в рамках, вы в порядке.

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