@Laborant666

Приветствуется ли в плюсах полностью ооп проект? По аналогии с джавой, как сказал один джавист - функций нельзя сделать вообще, можно сделать похожее только через класс с одним методом.
Так вот собственно и вопрос - ооп круто, но стоит ли полностью на ооп делать проект? В данный момент, в рамках одного моего проекта - так сделать можно, но будут классы без данных, чисто методы и всё, по смыслу разбитые на классы

0

@lemegeton

Вообще желательно использовать как можно меньше методологий.
Фигачите в ООП -- фигачте в ООП.
Фигачите функциональщину -- фигачте функциональщину.

Начинаете смешивать -- начинается бардак. Поэтому в яве, например, функциональщина выглядит как сова на глобусе.

Добавлено через 1 минуту
Да пожалуйста. Чистота кода мало зависит от методологии.

Как оценить "стоит/не стоит": выпишете все плюсы и минусы, сравните, что больше подходит в вашей ситуации.

1

@Laborant666

Даже если есть функция, которая никак не граничит со всеми имеющимися и получится класс с одним методом - всё равно делать класс, если решено использовать ооп? А как же тогда библиотеки, в которых и классы и функции?

0

@lemegeton

Так часто бывает. Обычно называется "интерфейсы".

Добавлено через 42 секунды
Да пожалуйста. Это называется функтором.

Добавлено через 36 секунд
Если ломает вашу методолгию -- методы оборачиваются в классы-функторы.

1

@Laborant666

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

0

@lemegeton

Попробуйте.

Добавлено через 4 минуты
В плюсах, в отличие от упомянутой ранее явы, есть несколько неудобств связанных с "абсолютным" ООП, делающих код на одном только ооп куда более многословным и несколько менее читаемым.

Я бы выделил отсуствие сборщика мусора, без которого начинается куча кухни вроде правил трёх/пяти, умные указатели и тому подобный ручной менеджмент памяти; а ещё я бы выделил особенную и систему (явных) ссылок и указателей, которая тоже делает код более многословным относительно упомянутой явы.

Не попробуете -- не узнаете. )

1

@hoggy

не надо использовать ооп там, где оно нафиг никому не нужно.

в процедурном.

кучка функций в стиле си - это процедурная парадигма.
не нужно путать её с функциональной парадигмой.

1

@Laborant666

Всё ж фукнциональное.. Процедура не возвращает результат, функция возвращает..

Добавлено через 8 минут
Давайте для примера - я могу сделать функцию поисковик изображения и кормить ей в параметры каждый раз скриншот и искомую картинку. Могу реализовать это вторым способом - и либо сделать рычаг внутри функции, либо создать вторую.
Могу сделать класс, в который при инициализации я буду класть искомую картинку, процент совпадения, количество объектов для поиска (один - все) и потом вызывать просто объект.Find(скриншот) и получать список совпадений. В плане этого будет в принципе та же функция, написано просто по-другому. НО!
Есть ряд преимуществ класса
1) Действия применяются относительно конкретного объекта и читается это легче, чем в параметрах функции
2) Если в функции нужно применить параметры отличные от дефолтных, то их каждый раз нужно писать теперь. В классе это делается 1 раз в инициализации. Что опять же делает код более читабельно
3) Рычаг на тип поиска с теми же исходными данными - в классе смотрится отлично, а вот в функции немного вычурно, да и рычаги, влияющие на результат функции с неизменными входными данными - не есть гуд. В классе это самой парадигмой предусмотрено, в парадигме функции сказано, что результат не должен меняться без изменения входных данных

Собственно поэтому я и подумал что полное ооп мне подойдёт лучше

0

@lemegeton

Разница между функциональным и процедурным подходом немного глубже.

Процедурное программирование это последовательное выполнение инструкций сверху вниз с условными или безусловными переходами.

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

Посмотрите, поглубже, вам понравится. )

Добавлено через 12 минут
Это вы говорите про организацию данных, а парадигмы "функциональное" или "объектно-ориентированное" программирование это про поведение.

1

@hoggy

попробуй в следующий раз сначала погуглить материал.

раз лучше, значит используй ооп.

0

@ablex

Фантазии какие-то... Нет бы взять и прочитать что есть что.

Тебе написали про твой же пример:
А не вообще про ООП.
Расшифровываю: если на С++ использовать функцию там, где это уместно, то ООП-парадигме, в которой может быть выполнен проект, это никак не повредит.

1

@Pphantom

Чистый ООП подходит далеко не для всяких задач. Да, есть случаи, когда он ложится на задачу идеально (вроде оконных интерфейсов), но просто загонять его везде - идея не лучшая. Написать-то рабочий код, возможно, и получится, но он будет откровенно избыточным.

0

@Laborant666

Это как раз из гугла 0.о

Добавлено через 1 минуту
Хм, гугл значит мне наврал немного. Понял

Добавлено через 1 минуту
Услышал вас и сегодня это ощутил

1

@hoggy

вот человек любезно предоставил доступное определение

есть такое понятие: императивная парадигма

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


на ней базируется процедурная парадигма

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


а вот функциональная парадигма, это уже не императив

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


на языке с++ функциональная парадигма используется в метапрограммировании

1

@Laborant666

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

Добавлено через 4 минуты
Из вики о фукнциональной парадигме

У меня нынче половина проекта на классах, половина на последовательном изменении состояний (сам порядок действий предопределен, но если что-то пойдет не так - код подстроится, сам или начнет сначала, или определит на каком шаге застрял и попытается с него стартануть ещё раз)

Добавлено через 3 минуты
Хм. А вчера в гугле читал что наоборот процедурка - зависит от данных, функциональщина от данных и ещё чего-то. Тут же читаю вики - всё наоборот. Вот почему я вчера так и ответил. За ссылки спасибо, думаю тему можно закрывать, большинство за то - что лучше использовать ту или иную парадигму - в зависимости от её надобности, эффективности или удобстве. В одно полностью топить не есть гуд

0

@John Prick

Нет. Это то же самое процедурное программирование.

В функциональном программировании сами функции являются объектами, могут быть переданы в другие функции, скомбинированы с другими такими же функциями и т.д.

1

@Laborant666

Передать функцию в другую функцию как аргумент?0.о
Если так - то передаётся результат функции, а не сама функция. И это равно тому же, что мы бы результат сохранили в переменную и эту переменную скормили другой функции. Синтаксис разный, а суть одна. Ну разве что переменная экономится
Либо я не так понял эту фразу

0

@John Prick

Типичный пример - callback, когда какая-то функциональная сущность (указатель на функцию, функциональный объект, лямбда-функция и т.д.) передаётся в другую функцию, которая уже её вызывает.

Добавлено через 7 минут
Вот например:
Здесь std::bind1st - это функция, принимающая на вход функциональную сущность (в данном случае экземпляр класса std::multiplies) и доп.параметр и возвращающая другую функциональную сущность - функциональный объект, который вызовет тот самый экземпляр std::multiplies для аргумента из входного вектора и доп.параметра.

1

@lemegeton

Даже не просто передать функцию в другую функцию.
А можно, например, подставить первые N-аргументов и передать такую функцию дальше. )
Пройдите коротенький туториал, скажем, по хаскелю. Отпадёт множество вопросов.

1

@SmallEvil

lemegeton, у меня небольшой вопросик.
Где почитать причины существования, а главное использования, такого разнообразия языков и парадигм ?
Где они используются, а не когда-то использовались, для каких задач ?

0