Парадигмы: императивная vs ООП

Здравствуйте, форумчане. Меня мучает проблема, можно так сказать, эстетически-идеологического характера. Суть заключается в следующем:

Концепция разделения данных и управления данными ООП дает большие преимущества - по крайней мере если алгоритмы имеют сложную структуру, то классы не дают превратиться в кашу из данных и обработчиков этих данных, что может случиться, если использовать императивный стиль программирования. С другой стороны ООП заточен на представление всего и вся в виде объектов. И во многих случаях это естественно и правильно. Например при написании персонажей в игре. Поскольку персонаж - это без сомнения объект.

Но беда в том, что не всегда что-то стойко ассоциируется с объектом. Например у меня есть модуль, который грубо говоря содержит 3 основных функции: шифрование по ГОСТ 28147-89 в режиме простой замены, шифрование по ГОСТ 28147-89 в режиме гаммирования и хеш-функция по ГОСТ 34.11-94. Последние две функции используют первую для своих вычислений. Есть еще вспомогательные функции. А еще есть данные, которые кое как распиханы по функциям. И я явственно вижу, что применив ООП парадигму, я смогу улучшить этот модуль - сформируется четкий интерфейс, данные будут размещены в одном месте, а следовательно, не будет всего этого дрочерства с передачей кучи параметров от одной функции к другой.

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

Нет стойкой ассоциации с объектом. Шифратор.вычислиХешФункцию("in god we trust"), Сортировщик.отсортируйМассив(arr) - все это как-то глупо и неестественно. Вот и спрашивается - как можно сделать элегантно - чтоб и данные с функциями не мешать, и чтоб потом как простые функции вызывать можно было? Есть, конечно, функторы, но объект все равно нужно где-то создать. Еще можно данные вынести в глобальную область - но мне всегда твердили, что глобальные переменные - это зло. Где истина?

0

Сделать соответствующие методы статическими в классе
Добавлено через 1 минуту

Сообщение от PitMagnum конечно, функторы, но объект все равно нужно где-то создать.

Для функтуров зачем ?

Добавлено через 2 минуты

Сообщение от PitMagnum Еще можно данные вынести в глобальную область - но мне всегда твердили, что глобальные переменные - это зло. Где истина?

Собственно зло... если данных много то тут без классов нормально не получится.

Главное в этом всю картину объять и понять что действительно нужно пользователю и как все сгруппировать.

0

Сообщение от PitMagnum Где истина?

Истина в том, что объект имеет состояние. Вычислятор синусов состояния не имеет, он всегда выдаёт один и тот же синус, поэтому вполне может быть просто функцией (чтоб не мешалась, можно засунуть в неймспейс).

С хеш-функцией то же самое. Если это вычислиМнеMD5(), то у неё нет состояния. Если же это объект "вычислитель хеш-функций", то у него есть состояние: текущий алгоритм, по которому он вычисляет хеш-функцию. Но его можно превратить в функцию, которая не имеет состояния, если она будет принимать этот алгоритм как аргумент. Соответственно, можно и наоборот: сделать объект, который будет хранить это состояние у себя, а его метод будет подсовывать это состояние stateless-функции.

0

Сообщение от ~OhMyGodSoLong~ Истина в том, что объект имеет состояние. Вычислятор синусов состояния не имеет, он всегда выдаёт один и тот же синус, поэтому вполне может быть просто функцией (чтоб не мешалась, можно засунуть в неймспейс). С хеш-функцией то же самое. Если это вычислиМнеMD5(), то у неё нет состояния. Если же это объект "вычислитель хеш-функций", то у него есть состояние: текущий алгоритм, по которому он вычисляет хеш-функцию. Но его можно превратить в функцию, которая не имеет состояния, если она будет принимать этот алгоритм как аргумент. Соответственно, можно и наоборот: сделать объект, который будет хранить это состояние у себя, а его метод будет подсовывать это состояние stateless-функции.

Статические методы И статическая переменная, хранящая состояние, не?

0

А если потребуется несколько состояний одновременно хранить?

0

0

Блин, а про статические методы я и не подумал совсем.. спасибо, такая концепция меня вполне устраивает.

Для функтуров зачем ?

ну дык..

сначала создаем объект, потом пользуемся как функцией.. или вы не об этом?

Императивная парадигма является противоположностью декларативной, но не объектной

я с этим абсолютно согласен, это я в данном контексте поставил vs в заголовке, и то это не совсем корректно, конечно.

~OhMyGodSoLong~, а разве несколько состояний нельзя хранить нельзя хранить в нескольких статических переменных? Ну, естественно, если это две разные категории состояния. Если нужно хранить несколько состояний одной категории, то если я все правильно понял, это возможно только при двух объектах с разными состояниями. Но здесь-то и противоречий в таком случае не возникает - объект сам собой напрашивается.

Меня еще один вопрос интересует - операторы cin и cout являются по сути классовыми объектами. А где они создаются?

0

Сообщение от PitMagnum Меня еще один вопрос интересует - операторы cin и cout являются по сути классовыми объектами. А где они создаются?

Это глобальные константы. Как и все остальные глобальные объекты, они инициализируются в начале выполнения программы перед выполнением кода main().

0

Сообщение от PitMagnum операторы cin и cout

Это не операторы, а объекты классов std::istream и std::ostream.

Сообщение от ~OhMyGodSoLong~ Это глобальные константы.

С чего это они константы?

0

Попробуй измени их)

0

Сообщение от Toshkarik С чего это они константы?

В смысле неизменяемости привязок имён std::cin и std::cout к объектам, а не неизменяемости состояний этих объектов. Состояния этих объектов стандартных потоков можно изменять, но так как для них не определёно присваивание, то cout нельзя заставить выводить информацию куда-то в другое место.

0

ОО - часть императивной: императивное программирование - это написание текстов, указывающих, что, как и с чем надо сделать, но не что в результате получить, а ООП - это написание текстов, указывающих, что, как и с чем надо сделать + декомпозиция задачи на основе типов данных + объединение подпрограмм с типами данных, ими обрабатываемыми + объединение свойств целого в единую сущность. По самой ОО из этого следует, что ОО - прямой потомок императивной парадигмы.

0

Герц, Пожалуйста:
Добавлено через 2 минуты

Сообщение от ~OhMyGodSoLong~ cout нельзя заставить выводить информацию куда-то в другое место

В любой книге сказано, что по умолчанию cout привязан с монитору, и что это можно изменить. Так же как и cin привязан к клавиатуре, и это тоже можно изменить.

0

Сообщение от Toshkarik В любой книге сказано, что по умолчанию cout привязан с монитору, и что это можно изменить. Так же как и cin привязан к клавиатуре, и это тоже можно изменить.

Продемонстрируйте, пожалуйста, на примере:

0

1

А как зовут поток принтера?

0

Toshkarik, спасибо за исправление. Никогда особо не дружил с плюсовыми потоками :(

Сообщение от taras atavin А как зовут поток принтера?

Эээ... Файл с именем LPT1, PRN или там /dev/pr0? Боюсь, это всё же ОС-специфичная вещь.

0

Виндузячий дефолтный принтер.

0

Сообщение от taras atavin А как зовут поток принтера?

Что тут имеется ввиду под "принтером", и какого рода должно быть название?

Сообщение от ~OhMyGodSoLong~ Никогда особо не дружил с плюсовыми потоками

По большому счету, они мало чем отличаются, основное отличие это, как раз, в объектах класса streambuf и объектах классах производных от него ( filebuf в файловых потоках и stringbuf в строковых потоках ).

Добавлено через 3 минуты
taras atavin, если имеется ввиду физическое устройство принтер, для распечатки текста на бумаге, это это, как и сказал ~OhMyGodSoLong~, платформозависимое API. В самом C++ ничего нет для работы с принтером.

0

Сообщение от Toshkarik и какого рода должно быть название?

Идентификатор конечно. Что же ещё?

0