Бизнес-логика должна быть помещена в домен или сервисы?
Ваше предположение о том, что ссылочный параметр rvalue подразумевает «вступление во владение», совершенно неверно. Ссылка Rvalue - это просто особая ссылка, которая поставляется с собственными правилами инициализации и правилами разрешения перегрузки. Не больше, не меньше. Формально он не имеет особого сходства с «перемещением» или «захватом» объекта, на который имеется ссылка.
Это правда, что поддержка семантики перемещений считается одной из основных целей ссылок на значения, но все же не следует предполагать, что это их только цель и что эти особенности как-то неразделимы. Как и любая другая языковая функция, она может позволить значительное количество хорошо разработанных альтернативных идиоматических применений.
Пример цитаты, похожей на ту, которую вы только что цитировали, фактически присутствует в самой стандартной библиотеке. Это дополнительные перегрузки, введенные в C ++ 11 (и C ++ 17, в зависимости от некоторых нюансов)
template< class CharT, class Traits, class T >
basic_ostream< CharT, Traits >& operator<<( basic_ostream<CharT,Traits>&& os,
const T& value );
template< class CharT, class Traits, class T >
basic_istream<CharT,Traits>& operator>>( basic_istream<CharT,Traits>&& st, T&& value );
Их основная цель - «преодолеть» разницу в поведении между членами и не перегрузки элементов в operator <<
#include <string>
#include <sstream>
int main()
{
std::string s;
int a;
std::istringstream("123 456") >> a >> s;
std::istringstream("123 456") >> s >> a;
// Despite the obvious similarity, the first line is well-formed in C++03
// while the second isn't. Both lines are well-formed in C++11
}
Он использует тот факт, что ссылка на rvalue может связываться с временными объектами и все еще видеть их как изменяемые объекты. В этом случае ссылка rvalue используется в целях, которые не имеют ничего общего с семантикой перемещения. Это совершенно нормально.
4 ответа
Логика, которая является частью доменной логики Пользователя, должна остаться в пользователе. Это может или не может связать введение Пользовательского объекта с сервисом. Я думаю, что это зависит от того, является ли сервис частью бизнес-логики Пользовательского класса, и придерживается ли выполнение этого Вашего повсеместного языка.
Я записал бы это:
class ShoppingCartService
{
private EmailService emailer;
public void addItemToUserCart(User u, Item i)
{
u.addItemToCart(i);
this.emailer.sendEmailTo(u, "Item " + i.toString() + " was added to your cart");
}
}
Этот связанный вопрос имеет обсуждение, которое Вы могли бы найти полезным.
Я также советовал бы Вам сохранять методы считывания и методы set максимально ограниченными в объеме для сокращения связи.
В больших системах Пользовательский класс закончил бы тем, что имел много различных видов операций. Класс мог бы стать слишком большим. Избегать, чтобы, были другие классы, которые делают вещи для пользователя.
"Однако это приводит к довольно анемичному домену (т.е. Пользовательский класс является только методами считывания/методами set)"
Пользователь не является целым доменом.
У Вас есть Корзина, Объект, и сложный Cart.add() это помещает Объекты в Корзину.
Таким образом, что, если Пользовательский класс кажется упрощенным?
Сохраните метод, как, Затем создайте класс обслуживания для обработки транзакции. Когда вызов выполняется к методу класса обслуживания, затем можно ввести логику пользования электронной почтой там.