Где создавать объекты классов?

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

А то у меня создание объектов разбросано по всей программе,
может это нужно делать где-то в одном месте? (обычно подключаю *.h - файлы, а не *.cpp, как здесь,
не стал писать, чтоб упростить пример)

И правильно-ли, что объекты нужно создавать только в *.cpp - файлах, а в *.h - нельзя?

0

Сообщение от taras atavin Дело не в том, что к нему нельзя достучаться, а в том, что потом ты запутаешься, что у тебя где валяется.

Обязательно запутаетесь, особенно, если писать код сдуру. Ваш первоначальный тезис — объявлять типы и объекты там, где они будут использоваться, он замечательный. Но польза от него такая же, как от совета не допускать ошибок. Программист будет ошибаться, и он будет писать объявления не там, где нужно. Рекомендуемая стратегия по уменьшению области видимости/доступа вытекает из необходимости уменьшения связности программы. Держать в голове взаимосвязи типов и объектов в программе существенно сложнее найти «потерявшуюся» переменную.

0

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

0

Сообщение от taras atavin Проблема таких отвлечённых рекомендаций в том, что всегда найдётся псих, который посоветует всё в глобал вытащить и "обоснует" это тем, что всего лишь один объект не является частью другого.

Рекомендация это не правило, а из ее обоснования должно приходить понимание ее применимости. Можно давать советы «всегда думать головой» и «писать код без ошибок», но они бесполезны.

Добавлено через 9 минут

Сообщение от taras atavin И связей между целыми объектами даже в суперкривом проекте меньше, чем в не ООП проекте на аналогичную тему скалярных переменных, которые могут потеряться.

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

0

Нельзя даже подумать о строке, не вспомнив, что она состоит из символов. Нельзя подумать об автомобиле и забыть, что двигатель - его часть. И если он у вас валяется отдельно - это плохо. Так же плохо, если цилиндры связаны сразу с булыжниками. А если спрятаны глубоко в двигатель и непосредственно не доступны - хорошо. Потому что снаружи они не нужны. В public вообще уместно выносить только интерфейсы, если член класса - как раз часть интерфейса - выноси в палбоик, не стесняйся. Только зулус способен помыслить о телевизоре, забыв об интерфейсе выбора каналов. Причём, если он в поте лица своего этот интерфейс выбрал, а тем более с ноля придумал, то ещё и во всех подробностях его. Но очень плохо, если телевизор валяется в цилиндре двигателя, как не выкручивайся с пабликом, а такое будет быстро забыто. Весь телевизор лучше или в глобал, или в склад телевизоров. Ну в крайнем случае в склад бытовой техники вообще. Опять таки будет трудно забыть, из чего он состоит. Не возможно забыть, что печь имеет футеровку, а электропечь электроды. Не возможно забыть, что электроприбор имеет такие свойства, как напряжение питания, потребляемый ток, вид тока, а если ток переменный. то ещё и количество фаз и частоту. И от размеров иерархии объектов принципиально ничего не меняется, если структура стройна, забыть её сложно. А рекомендация прятать объект в максимально закрытую область, выполняемая без критического анализа, как раз и выльется в телевизор внутри клапана. И в избыток связей и интерфейсов.

Добавлено через 3 минуты

Сообщение от shuffle Высокая связность — единственная проблема, для решения которой вообще придуманы все механизмы ограничения доступа, пространств имен и методик рефакторинга. Для чего бы еще они были нужны, если вы и так пишите все там, где надо?

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

Добавлено через 5 минут
А сколько там всего типов - не принципиально. Я свободно ориентируюсь в паре миллионов хорошо связанных строк, но "утону" в пяти криво нагромождённых переменных двух скалярных типов, когда быдлокод и экран то целиком не занимает.

0

Сообщение от taras atavin В public вообще уместно выносить только интерфейсы, если член класса - как раз часть интерфейса - выноси в палбоик, не стесняйся

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

0