Избегайте возврата дескрипторов к внутренним элементам объекта, так что же есть альтернатива?

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

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

Теперь не имеет значения, является ли ссылка, которую вы возвращаете, const или нет: вы случайно раскрываете тот факт, что у вас есть объект Mother внутри вашего класса Family, и теперь вы просто не можете избавиться от него (даже если у вас есть лучшее представление) потому что все ваши клиенты могут зависеть от него и должны будут изменить свой код...

Самое простое решение - вернуть по значению:

class Family {
public:

    Mother mother() { return _mother; }
    void mother(Mother m) { _mother = m; }

private:
    Mother _mother;
};

Потому что на следующей итерации я могу удалить _mother, не нарушая интерфейс:

class Family {
public:

     Mother mother() { return Mother(_motherName, _motherBirthDate); }

     void mother(Mother m) {
         _motherName = m.name();
         _motherBirthDate = m.birthDate();
     }

private:
     Name _motherName;
     BirthDate _motherBirthDate;
};

Видите, как мне удалось полностью переделать внутренности, ни на йоту не изменив интерфейс? Очень просто.

Примечание: очевидно, что это преобразование предназначено только для эффекта...

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

Возможные решения зависят от фактического дизайна ваших классов и того, что вы считаете «внутренностями объекта».

1. Mother — это всего лишь деталь реализации Family и может быть полностью скрыта от Family пользователя.
2. Family считается композицией других публичных объектов

В первом случае вы должны полностью инкапсулировать подобъект и предоставить доступ к нему только через Family функций-членов (возможно, дублируя Mother публичный интерфейс):

class Family
{
  std::string GetMotherName() const { return mommy.GetName(); }
  unsigned GetMotherAge() const { return mommy.GetAge(); }
  ...
private:
   Mother mommy;
   ...
};

Что ж, может быть скучно, если интерфейс Mother довольно большой, но, возможно, это проблема дизайна (хорошие интерфейсы должны иметь 3-5-7 элементов), и это заставит вас пересмотреть и переделать его в лучшую сторону.

Во втором случае вам все равно нужно вернуть весь объект. Есть две проблемы:

1. Разбивка инкапсуляции (код конечного пользователя будет зависеть от определения Mother)
2. Проблема владения (висячие указатели/ссылки)

Для решения проблемы 1 используйте интерфейс вместо определенного класса, для решения проблемы 2 используйте совместное или слабое владение:

class IMother
{
   virtual std::string GetName() const = 0;
   ...
};

class Mother: public IMother
{
   // Implementation of IMother and other stuff
   ...
};

class Family
{
   std::shared_ptr<IMother> GetMother() const { return mommy; }
   std::weak_ptr<IMother> GetMotherWeakPtr() const { return mommy; }

   ...
private:
   std::shared_ptr<Mother> mommy;
   ...
};

Если вам нужно представление только для чтения, и по какой-то причине вам нужно избегать висячих дескрипторов, вы можете рассмотреть возможность возврата shared_ptr<const Mother>.

Таким образом, объект Mother может пережить объект Family. Который также должен хранить его по shared_ptr, конечно.

Часть соображений заключается в том, собираетесь ли вы создавать эталонные циклы, используя слишком много shared_ptr. Если да, то вы можете рассмотреть weak_ptr, а также рассмотреть возможность просто принять возможность висячих дескрипторов, но написать клиентский код, чтобы избежать этого. Например, никого особо не беспокоит тот факт, что std::vector::at возвращает ссылку, которая становится устаревшей при уничтожении вектора. Но тогда контейнеры являются крайним примером класса, который намеренно раскрывает объекты, которыми он «владеет».

Это восходит к фундаментальному принципу ООП:

Tell objects what to do rather than doing it for them.

Вам нужно Mother, чтобы сделать что-то полезное? Попросите объект Family сделать это за вас. Передайте ему любые внешние зависимости, завернутые в приятный интерфейс (Class в С++) через параметры метода объекта Family.

потому что это может привести к «висячим дескрипторам», что означает, что вы сохраняете ссылку на член объекта, который уже уничтожен.

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

Это просто вопрос семантики. В вашем случае Mother — это не Family внутренности, а не детали его реализации. На экземпляр класса Mother можно ссылаться в Family, а также во многих других объектах. Более того, время жизни экземпляра Mother может даже не коррелировать со временем жизни Family.

Таким образом, лучшим дизайном было бы хранить в Family shared_ptr<Mother> и без проблем выставлять его в интерфейсе Family.