Сколько объектов внутри класса слишком много? - PullRequest
3 голосов
/ 01 июля 2011

Я довольно плохо знаком с концепциями ОО-программирования - вообще-то, программированием, так как я еще студент. В настоящее время я работаю стажером в отделе, в котором я пишу новую структуру, которая, вероятно, станет основой для всех их приложений. Таким образом, я полагаю, что в основе ОО лежит идея о том, что вы создаете «базовые строительные блоки», а затем расширяете, расширяете и расширяете, пока не достигнете самого сложного объекта (в настоящее время).

Мне нужно собрать все эти "продвинутые" объекты в один, но сколько их слишком много? Могу ли я иметь 100 объектов внутри этого большего объекта, если для этого нужны все эти "части".

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

Спасибо.

РЕДАКТИРОВАТЬ 1: Большое спасибо за ваши ответы, но я все еще немного неясен. Я уже пометил ответ, так как чувствовал, что могу продолжить то, что у меня есть, но ...

Позвольте мне продолжить мой человеческий пример. Человек состоит из множества частей (или объектов), и каждая часть также состоит из частей, вплоть до одной клетки.

Человек -> Рука -> Рука -> Пальцы -> Большой палец -> Кости -> Костные клетки

Человек: ojbLeft_Arm, objRight_Arm, objLeftLeg, objRightLeg, objBrain, objHeart, objLeft_Eye, objRight_Eye .... получить мою точку зрения? Сколько объектов внутри человеческого объекта слишком много? Очевидно, что этот Человеческий объект будет считаться массивным, так как Человек очень сложный. Разбиваете ли вы объекты Arm и Leg на objLimbs, которые затем сохраняют их?

Наверное, еще один вопрос: если вам не нужно много объектов, КАК избегаете ли вы их?

Ответы [ 2 ]

9 голосов
/ 01 июля 2011

100 объектов внутри одного объекта не являются строго неподходящими, но это определенно указывает на то, что может быть лучший способ сделать это. Рассмотрите возможность группировки похожих объектов в составные объекты, где функциональность аналогична для использования в вашем конечном «суперобъекте». Как правило, количество объектов, на которые вы ссылаетесь в классе, является (грубой) оценкой сложности этого объекта; 100 означает сложность, которая слишком высока. Обратите внимание, что вы можете уменьшить эффективную сложность, сгруппировав объекты в составные объекты, тем самым увеличив общее количество объектов, но уменьшив количество прямых ссылок в своем «суперобъекте».

Правка в ответ на правку OP и вопрос: ключ к группировке - это действительно ожидаемое использование и проблемная область. Посмотрите на ваш человеческий пример; Соответствующая разбивка объектной модели действительно зависит от использования вашей модели данных. Ключевым моментом здесь является признание того, что вы НЕ пытаетесь представить все возможные объекты или основную реальность; вы создаете представление, соответствующее вашему ожидаемому использованию. Например, если вы моделировали человека для кардиолога, возможно, было бы целесообразно иметь объект человека, под которым у вас будет объект сердца, объект кровеносной системы и т. Д .; под объектом «Сердце» у вас могут быть левый желудочек, правый желудочек и т. д. Однако для дантиста ваша модель все равно будет иметь человека наверху, но у человека, скорее всего, будет коллекция зубов на следующем уровне; зубы могут включать объекты для клыков, резцов и т. д.

Ключевым моментом здесь является то, что базовый объект (человек) одинаков; представление совершенно другое. Ваш кардиолог не очень заботится о ваших зубах, а ваш стоматолог не заботится о ваших желудочках сердца. Использование определяет представление. Так что для вашего случая вы должны точно определить, что вы используете, и это использование может (надеюсь) определить четкий путь к вашему представлению.

4 голосов
/ 01 июля 2011

Существует предел того, что программист может запомнить.

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

Стив Макконнелл рассматривает эту проблему в книге " Код завершен, второе издание "

Критикуйте классы, которыесодержит более семи элементов данных Было обнаружено, что число "7 ± 2" является числом отдельных элементов, которые человек может запомнить при выполнении других задач (Miller 1956).Если класс содержит более семи членов данных, подумайте, нужно ли разбивать этот класс на несколько более мелких классов (Riel 1996).Вы можете ошибиться больше в верхнем конце 7 ± 2, если члены данных являются примитивными типами данных, такими как целые числа и строки, больше в нижнем конце 7 ± 2, если члены данных являются сложными объектами.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...