C++ DAL - Возвратите ссылку или заполните, передал в ссылке
... мне могло сойти с рук просто принятие, в спящем режиме для простых вещей, которые я должен сделать?
Да
В спящем режиме, для ORM (возразите реляционному отображению) то есть, сделайте свои объекты персистентными к RDBMS.
Spring идет далее. Это может использоваться также в качестве AOP, Инжектора Зависимости, веб-приложения и ORM среди прочего.
Поэтому, если Вам только нужен ORM, просто используйте, в спящем режиме. Время настанет, когда Вам будет нужен Spring, и Вы изучите это затем.
Вот архитектурное представление Spring:
И это, Будьте в спящем режиме:
2 ответа
Второе однозначно предпочтительнее. Вы возвращаете ссылку на новый объект. Для конечного пользователя, использующего программное обеспечение, не очевидно, что возвращенный объект потребует удаления. ПЛЮС, если пользователь сделает что-то вроде этого
Car myCar = dal.loadCar( id );
Указатель потеряется.
Ваш второй метод, таким образом, передает управление памятью вызывающей стороне и предотвращает появление каких-либо странных ошибок.
Изменить: возврат по ссылке имеет смысл но только тогда, когда родительский, то есть DAL, класс имеет контроль над временем жизни ссылки. то есть, если бы в классе DAL был вектор объектов Car, то возвращение ссылки было бы совершенно разумным делом.
Edit2: Я бы все равно предпочел вторую настройку. Третий вариант намного лучше, чем первый, но в конечном итоге вы заставляете вызывающего пользователя предполагать, что объект инициализирован.
Вы также можете предоставить
Car DAL::loadCar(int id);
И надеяться, что примете копию стека.
Также не забывайте, что вы можете создать своего рода нулевой объект car, чтобы вы возвращали объект, который является «действительным», но возвращает вам нет полезной информации во всех полях (и, следовательно, очевидно, что он инициализирован как ненужные данные). Это шаблон нулевого объекта.
Поскольку вы все равно размещаете объекты в куче, почему бы не рассмотреть Car * LoadCar (), который возвращает NULL в случае возникновения проблемы. Таким образом, у вас нет ограничений на ссылочные типы (каждая ссылка должна быть инициализирована), а также есть средства для сообщения о случае ошибки.