Агрегатные объекты

Question

Если у вас есть класс А, который представляет собой совокупность класса B и C, является его лучше для

• для хранения идентификаторов для B и C
• для загрузки и хранения всего объекта для в и с (редактировать, хранить в виде ссылки на объект B/C, то есть создавать объекты в и с, в отличие от хранения идентификаторов для B и C.
• магазина идентификатор и обеспечить методы, чтобы тянуть методы в и с

Я предполагаю, что это зависит от сущности а также другие требования, но я просто ищу любые общие рекомендации или мысли.

Answer 1

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

Загрузка и хранение «Цельного объекта» является сомнительной концепцией. Я знаю, что вы пытаетесь быть независимыми от языка, но одна из первых вещей, которые действительно помогли мне «Получить» OO, состоит в том, что почти каждый объект должен иметь собственный жизненный цикл.

Если у вас есть объект A, который содержит «Содержит» объект B, и вы передаете ссылку на объект B на объект C, тогда объект A должен знать что-то о объекте C, это не совсем нормально. Освобождение жизненного цикла объекта B, чтобы объект A ничего не знал о объекте C, является одним из основных понятий, которые делают работу OO.

Итак, если это то, что вы имели в виду, сохраняя весь объект, тогда нет - никогда не делайте этого.

И это справедливо и для баз данных и другого хранилища. Даже если один объект отвечает за уничтожение другого, он редко должен содержать данные других объектов.

И (хотя я думаю, что вы хотели сказать «вытащить объекты B и C», а не «методы»), понятие о возможности передать объект из другого также очень полезно, и, как правило, в нем нет ничего плохого с одной оговоркой:

Помните, что объект не имеет контроля над тем, что происходит снаружи. Его можно обойти, методы, называемые в полуслучайном порядке, и т. Д. Поэтому полезно держать ваш объект как можно более безопасным. Если что-то вызывается в неправильном порядке или передается недопустимая переменная или вы обнаружите, что каким-то образом вы ввели недопустимое состояние, Fail early и Fail LOUD так, что программист, совершивший ошибку, назвал это.

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

Answer 2

Это зависит от ситуации. Если объекты остаются в памяти, больше OO (и проще) иметь A содержат B и C. Я обнаружил, что если объекты должны быть сохранены, тем не менее, это упрощает и повышает эффективность A для хранения идентификаторов для B и C. (Таким образом, если вам необходимы данные непосредственно в а, но не в и с, вы не должны тянуть B и C из базы данных, файлов и т.д.)

Answer 3

Это зависит,

Если B и C являются тяжелыми, а затраты на загрузку и сборку, возможно, стоит отложить загрузку их, пока вы не уверены, что они необходимы (Lazy Initialize).

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

Answer 4

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

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

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

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