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

@PitMagnum · Регистрация: 28.05.2012

Author24 — интернет-сервис помощи студентам

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

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

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

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

C++

1 2	Math mth; x = mth.sin(y);

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

@nshell32gmail · 19.12.2012, 17:07

Сообщение от ~OhMyGodSoLong~

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

статический массив,

C++

class alg{
private:
const int state_count = 5;
int state[state_count];
public:
void setState(int state, int value)
{
///...
this->state[state] = value; 
///...
}
int getState(int state)
{
///...
return this->state[state];
///...
}
};

или флаги состояний, если состояния булевые.

C++

class abc{
private:
int mask;
public:
abc():mask(0) {}
void setState(int state, bool value)
{
//...
if (value)
mask |= 1<<(state-1);
else
mask -= 1<<(state-1);
//...
}
bool getState(int state)
{
return (mask && (state-1));
}
};

Jupiter · 19.12.2012, 17:18

Сообщение от ~OhMyGodSoLong~

Истина в том, что объект имеет состояние

имеет, а может и не иметь, вычисление того же синуса разными алгоритмами например, полиморфизм же

Jupiter Каратель 6609 / 4028 / 401 Регистрация: 26.03.2010 Сообщений: 9,273 Записей в блоге: 1
	19.12.2012, 17:18	22
	Сообщение от ~OhMyGodSoLong~ Истина в том, что объект имеет состояние имеет, а может и не иметь, вычисление того же синуса разными алгоритмами например, полиморфизм же 0