Как перегрузить оператор и не вызвать ненависть коллег?

Question

[Bogdan]

Осваиваю ООП на собственном маленьком проекте. Столкнулся с вопросом как изящно организовать сложение в простеньком классе. Класс содержит всего 2 переменные:

qint64 value; 
pm_currency_t currency; // тип валюты

С одной стороны я хочу реализовать возможность сложения для этого класса, с другой я не хочу позволять сложение с разным типом валюты.
Насколько хорошей идеей будет перегрузка '+' для этого класса?
При попытке сложить разную валюту, какой будет лучшая реакция: возврат null_ptr, выброс исключения, что-то другое?

Comments

[Евгений Шатунов]

Bogdan , как ты планируешь пользоваться этим типом валюты относительно значения currency?
Тип валюты у тебя задается один раз и не меняется или ты хочешь в любое время менять этот тип?
Если у тебя, скажем, есть объект товара с ценой, то есть ли у тебя в требованиях возможность в любое время поменять тип валюты в его цене?

[Bogdan]

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

[Евгений Шатунов]

Bogdan, наверное мой вопрос слишком неоднозначный.
Вот что я хочу узнать. Сломается ли у тебя логика программы если валюту сделать шаблоном от параметра с типом pm_currency_t?

Например так.

template< pm_currency_t CURRENCY >
class Currency final
{
public:
// ...

private:
	int64_t m_value = 0;
};

Собственно, это и было бы моим ответом на твой вопрос. Исключения и прочие проверки не нужны в таком случае, транслятор обеспечит целостность операций с валютами.
Только это потребует на этапе кода знать куда и какую валюту ставить. А такое знание на этом этапе может оказаться невозможным. Поэтому я и задал свой вопрос.

[Bogdan]

Евгений Шатунов, Кажется, в моем случае - это отличный совет. Чтобы понять не сломает ли это программу, мне не хватает компетенции. Стоит попробовать, для этого программа и пишется

Answer 1

[Армянское Радио]

1) В данном случае, идея хорошая, так как семантика поломана не будет, но при условии, что
2) В случае несовпадения валют вы будете бросать исключение.

Пояснение: Если вы будете возвращать не валюту, (nullptr, false, не важно), вы сломаете семантику сложения, а это делать не следует. Так что ошибку надо обрабатывать в исключении.

Проблема: Если возникновение таких исключений будет частым (например, это часть бизнес-логики), у вас получится чуть более тормозная программа. В таком случае, лучше отказаться от перегрузки оператора и написать обычный метод.

Если же валюта вам известна уже на этапе компиляции, переделайте ваш класс в шаблон и делайте все проверки уже на этапе компиляции - это наилучший вариант.

Comments

[LoliDeveloper]

Исключения на плюсах это же ошибка природы

[Армянское Радио]

LoliDeveloper, без аргументов (очень серьезных) - это звучит как фраза человека, который начитался популярных блоггерков.

[LoliDeveloper]

Бобби Шифер, так и планировалось)
Вообще у нас лекторы так говорили и ссылались что в гугле так принято, значит так правильно.

[Армянское Радио]

LoliDeveloper, если так говорит практикующий программист на C++ - он не владеет своим инструментом в полной мере. У исключений есть как pros так и cons и выбор в пользу того или иного делается в контексте задачи, а не на основании того, что кто-то там что-то там наболтал у себя в блоге, на лекции, на митапе и так далее.

В своем ответе я как раз и привел pros (не ломается семантика выражений) и cons (если пустить бизнес-логику через исключения, можно получить тормоза. Причем есть вероятность, что это приемлемо).

[LoliDeveloper]

Бобби Шифер, та та