А вопрос-то в чём?
Нужна функия? Пиши функцию.
Нужен метод класса? Пиши метод класса.

P.S. Обчитаются своего Чаушеску и начинают вместо написания логичного кода размышлять об абстракциях...

В случае голого ООП... кажется порочной практикой

Классы удобны на множествах данных с похожими, но не тождественными операциями. Функции — для однотипных данных.

Для простоты будем считать, что это функции для калькулятора (+-*/)

Для действительных чисел стандартных функций (+-*/) «хватит всем». Но ежели добавить комплексные, кватернионы, матрицы, ... то классы становятся полезны.

Объявляю холивар открытым.

Котлеты (классы) — отдельно, мухи (функции) — отдельно. [/холивар] :)

Есть языки в которых всё явно класс

И это маразм.

Не понял, а почему нельзя сделать абстрактный класс MathOperation, от которого унаследованы sum, sub, mult, div?

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

Вообще, ОП, что сказать-то хотел?

Я за все есть объект, но против мешаний ничего не имею.

можно использовать функции, создаются 4 функции sum, sub, mult и div

Ага, а потом начнется calc_sum, array_sum, time_sum, и чем это лучше Calc::sum, Array:sum, Time::sum? Да еще и вылезет конфликт с какой-то библиотекой.

Что бы не было суперклассов надо делать декомпозицию (в описанном случае на функторы) а не кричать что ООП фекалии и надо юзать функции.

ООП не так прекрасно как малюют сейчас и тем более как малевали в 90ые-00ые, но недостатки у него другие и перекрываются они рядом достоинств, так что всё не супер однозначно.

В случае голого ООП, можно создать некрасивый класс super_puper_calculator в котором определить методы sum, sub, mult и div, что, лично мне, кажется порочной практикой, т.к. подобные классы порой напоминают «божественные»

Это тоже самое только плюс к этому типа неймспейс из твоего класса, а так они у тебя все глобальные. Никакой разницы короче, что то дерьмо, что это. Применение mixin'ов смотрится логичнее но эта ваша фп и оопота на них клала и нормально реализованы они только во всякой клятой динамике типа пистона и жс.

ООП на практике - тот самый хвост, который пытается вихлять собакой. Тебе решать, насколько сильно ты готов отдаться хвосту. Или, быть может, сразу отсечь его? К хренам собачьим?
Предварительно поигравшись и испытав на вшивость...

:-D

а потом начнется

Обычно так оно и происходит.

К чему эти функции лепятся? Всё есть объект, у обьептов есть методы. Тип Вариант остался в вижуал-васике.

Ловите наркомана, а то в декларативщика мутирует!

в C# есть делегаты для такого

К чему эти функции лепятся?

К пространству имён же. Класс или нет, какая разница.

бросаю на вентилятор

считаю, что автор недостаточно углубился в вопрос. по ооп будет класс super_puper_calculator, у которого есть только do_calc(node&) производящий вычисление значения выражения. классы sum, sub, mult, div будут наследоваться от node. так же как и number, без которого в данном вопросе тоже обойтись трудно.

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

ООП

Создать объекты Сумматор, Умножитель и т.д.

Посылать им сообщения.

Нет универсального ответа

Ну надо же, для разных задач подходят разные инструменты.

Ага. Я знаю. Более того, это всегда компромисс. Так как даже разные инструменты не идеальны.