В типичной программе, работающей в памяти, объекты почти всегда сохраняются по ссылке в виде указателей, поэтому вы сохраняете идентификаторы для B и C, просто вы сами не разбираетесь в деталях, язык скрывает их от вы.
Загрузка и хранение «всего объекта» является сомнительной концепцией. Я знаю, что вы пытаетесь быть независимым от языка, но одна из первых вещей, которые действительно помогли мне «получить» ОО, заключается в том, что почти у каждого объекта должен быть свой жизненный цикл.
Если у вас есть объект A, который «содержит» объект B, и вы передаете ссылку на объект B на объект C, тогда объект A должен что-то знать об объекте C, это совершенно НЕ нормально. Освобождение жизненного цикла объекта B, чтобы объект A ничего не знал об объекте C, является одной из основных концепций, которая заставляет ОО работать.
Так что, если вы имели в виду, что хранили весь объект, то нет - никогда не делайте этого.
И это относится и к базам данных и другим хранилищам. Даже если один объект отвечает за уничтожение другого, он редко должен содержать данные других объектов.
И (хотя я думаю, что вы хотели сказать «тянуть объекты B и C», а не «методы»), концепция возможности передавать объект от другого также очень полезна, и в этом нет ничего плохого одно предостережение:
Помните, что объект не может контролировать то, что происходит вне его самого. Его можно передавать, вызывать методы в полуслучайном порядке и т. Д. Поэтому полезно сохранять объект максимально безопасным. Если что-то вызывается в неправильном порядке, или передается недопустимая переменная, или вы обнаружите, что каким-то образом вы вошли в недопустимое состояние, Fail early и Fail LOUD, так что программист, допустивший ошибку, вызвал это.
Вы также хотите максимально затруднить переход в недопустимое состояние - это означает, что ваш объект должен быть маленьким и простым, чтобы переменные всегда были окончательными, когда это возможно, и старались не иметь слишком много мест, где важен порядок вызова параметров.