Стоит ли использовать ООП?

Здравствуйте.
Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп?
Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами.
Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени.

5

Коллега Evg, я совершенно согласен с тем, что нужно или не нужно использовать ООП - сильно зависит от конкретной задачи. Тут консенсус. А вот на тех задачах, где время компиляции будет уже измеряться часами (а значит, число строк исходного кода - измеряется сотнями тысяч, если не миллионами LOC), - пожалуй, стоит уже использовать.
На тех же задачах, где два часа могут существенно повлиять на сроки исполнения проекта..... хм, а что за задачи-то такие? "Hello, World!" написать?

0

Сообщение от Evg Ты всегда можешь в отладчике поставить брейкпоинт на процедуру set - это намного проще, чем пытаться отловить точку, где произошла запись напрямую в твоё поле (адрес, куда реально идёт запись к тому же будет плавать от запуска к запуску)

Хм... об этом я не подумал - действительно удобнее.

Добавлено через 35 секунд
Такой еще вопрос.
На скорость выполнения программы ооп не влияет?

0

На скорость работы оказывают влияние алгоритмы присутствующие в программе, вроде так.

0

Сообщение от CheshireCat Коллега Evg, я совершенно согласен с тем, что нужно или не нужно использовать ООП - сильно зависит от конкретной задачи. Тут консенсус. А вот на тех задачах, где время компиляции будет уже измеряться часами (а значит, число строк исходного кода - измеряется сотнями тысяч, если не миллионами LOC), - пожалуй, стоит уже использовать.

Мы же договорились, что зависит от задачи То же самое ядро ОС, тот же самый компилятор. Понятно, что исходник компилятора не три часа собирается, но когда машина не "чистая" (т.е. на ней запущено какой-то тестирование), то время сборки компилятора gcc или ядра linux - довольно ощутимое

Сообщение от CheshireCat На тех же задачах, где два часа могут существенно повлиять на сроки исполнения проекта..... хм, а что за задачи-то такие? "Hello, World!" написать?

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

Просто лет 10 назад мы это уже проходили и в полной мере ощутили. Правда тогда у нас были sparc'и с частотой порядка 60 МГц, а на 3-ГГцовых машинах это скорее всего будет ощущаться в меньшей степени.

1

Может ещё что то влияет я не знаю точно, но алгоритмы в большей степени.

0

Сообщение от @KOT@ Такой еще вопрос. На скорость выполнения программы ооп не влияет?

Завист от конкретной реализации. Если ты set и get напишешь внутри класса, то любой вменяемый компилятор сделает inline-подстановку и код будет работать так, как будто ты пишешь напрямую в поле. Но если вынесешь эти процедуры в отдельный файл, то никакого inline не будет, ибо компилятор попросту внутренностей функции не увидит. В итоге на каждую запись поля вместо одного машинного такта будет их тратиться несколько десятков

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

Сообщение от Genius Ignat Может ещё что то влияет я не знаю точно, но алгоритмы в большей степени.

Когда тебе нужен список для конкретных задач, то ты можешь реализовать его сам наиболее оптимальным образом под свои нужды. А можешь использовать из стандартных шаблонов (stl). Во втором случае, как правило, код будет медленнее, чем в первом

5

@KOT@
Только не спрашивай о скорости работы программы, при наличии virtual.
ответ где то на форуме есть.

0

Сообщение от Evg Когда тебе нужен список для конкретных задач, то ты можешь реализовать его сам наиболее оптимальным образом под свои нужды. А можешь использовать из стандартных шаблонов (stl). Во втором случае, как правило, код будет медленнее, чем в первом

Спасибо, давно хотел об этом услышать По крайне мере я хоть как то успокоился и оправдал свои велосипеды которые недавно написал. Для игры важна скорость особенно во время рендера, stl вообще не пользуюсь почти.

Сообщение от Genius Ignat Только не спрашивай о скорости работы программы, при наличии virtual. ответ где то на форуме есть.

Мне кажется если человек не знает для чего ООП то для чего virtual ему рановато спрашивать

2 @KOT@ Ты вроде собирался редактор писать? Без String класса тебе будет сложнее это сделать. А если будут ошибки придется сложнее отлаживать.
Множество людей не могут ошибаться. ООП полезен, его надо использовать. Зачем отказываться от возможнсти если она есть? Новичку в какой то области всегда кажется сомнительным та или иная технология. Например люди с компьютером на "вы" могут поставить 1 программу определенного типа и использовать её всю жизнь (т.к. освоили - все понятно и просто, а новое страшно и мудрено). Даже если вы сейчас не хотите использовать в вашем конкретном проекте ООП, все равно стоит его изучить. Просто смысл в том что пока не попробуешь не прочувствуешь. Так что опыт, опыт, опыт решает. Дело не в ООП, дело в опыте

0

Сообщение от insideone Мне кажется если человек не знает для чего ООП то для чего virtual ему рановато спрашивать 2 @KOT@ Ты вроде собирался редактор писать? Без String класса тебе будет сложнее это сделать. А если будут ошибки придется сложнее отлаживать. Множество людей не могут ошибаться. ООП полезен, его надо использовать. Зачем отказываться от возможнсти если она есть? Новичку в какой то области всегда кажется сомнительным та или иная технология. Например люди с компьютером на "вы" могут поставить 1 программу определенного типа и использовать её всю жизнь (т.к. освоили - все понятно и просто, а новое страшно и мудрено). Даже если вы сейчас не хотите использовать в вашем конкретном проекте ООП, все равно стоит его изучить. Просто смысл в том что пока не попробуешь не прочувствуешь. Так что опыт, опыт, опыт решает. Дело не в ООП, дело в опыте

Нет - почему я изучаю (можно даже сказать почти доучил) ооп - не в том смысл, что я не знаю как оно работает.
Я просто предположил, что небольшие программы можно писать и без него, и возможно даже легче без ооп. Хотя некоторые доводы показались мне довольно убедительными. И я согласен, что в больших проектах ооп - очень даже уместно.
Но в мелких программах...

К тому же в си-шарп - без ооп вообще обойтись невозможно, так как там весь код содержиться в классах и методах(помоему в джава тоже). Я считаю это лишним. К тому же в си шарп, все типы (даже инт и чар) являются обьектами классов - правильно ли это для языка?
В этом плане си++ мне кажется более свободным (можно обойтись и без ооп).
+ я полностью поддерживаю ооп, там где обьекты сопоставлены с обьектами в реальном мире например в играх - обьект человек, а бежать это метод человека. Здесь ооп - лучшее средство.

Но при написании тех же берем крестиков - ноликов ооп абсолютно ни к чему.

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

1

Сообщение от @KOT@ К тому же в си шарп, все типы (даже инт и чар) являются обьектами классов

не все

0

Сообщение от HIMen не все

а какие не являются?

0

указатели

0

Сообщение от HIMen указатели

Ну а все остальные - обьекты. К тому же мелкософт не очень поддерживает использование указателей.

0

Сообщение от @KOT@ Я просто предположил, что небольшие программы можно писать и без него, и возможно даже легче без ооп. Хотя некоторые доводы показались мне довольно убедительными.

Было бы забавно если здесь кто нибудь предположил что все должны пользоваться ООП всегда и везде )) Кстати мне и мелкую программку бывает проще напсать из за ООП. 1) Повторно использую какой то класс и этим могу сделать 30% программы (маленькая же); 2) Легче воспринимать код -> легче отлаживать, легче дополнять, легче налаживать. Если говорить о совсем уж мелких программах то смысл их написания кроме учебного вообще теряется, а учебный процесс это другой вопрос. Иначе в голову и пример не приходит. Хотя согласен что без ООП ряд мелких задач может быть решен быстрее благорадя тому что не нужно "запариваться" на него

0

Сообщение от insideone Спасибо, давно хотел об этом услышать По крайне мере я хоть как то успокоился и оправдал свои велосипеды которые недавно написал. Для игры важна скорость особенно во время рендера, stl вообще не пользуюсь почти.

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

0

Ну я делаю по принципу конкретной задачи - все лишнее вон. Ведь stl она же универсальна и поэтому я как понимаю у неё есть минусы в скорости? Вообще говоря я прогонял некоторые stl вещи через пошаговый проход и это выглядело просто ужасно. В смысле можно час сидеть нажимать кнопку "следующая строчка" а в своем коде это реально видно что гораздо меньше. Это конечно не показатель, но все же выглядит подозрительно.

Ps. Это касается не только stl но и любых других вещей. Хотя функциям mem*** научился доверять. ASM внушает)

0

А тема растят...

0

В приложении к конкретной задаче обсуждении было бы более конкретным и интересным. Так что ждем что скажет @KOT@

0

В пользу ООП приведу рабочий живой пример - класс работы с комплексеыми числами - кода самого класса там на 68 строк.
Но зато при использовании формулы выглядеть горездо понятнее, чем если бы +, * и / я использовал функции
На счет Get и Set: возьмем тот же пример. Сейчас у меня действительная и мнимая часть записываются в x и y. Чтобы получить действительную и мнимую часть есть, положим, функции Re и Im, которые просто возвращают значения переменных. И меня это устраивает. Но вот для вычисления Log нужно хранить числа в тригонометрической форме. То есть, если бы я использовал поля x и y вместо Re и Im, то везде в коде, где я их использовал, мне нужно было бы что-то переписывать при изменении формы представления. А сейчас мне нужно поменять только сами функции Re и Im.
К тому же, очень редко модификаторы только возвращают и устанавливают значение. Вот у меня, например, функции SetRe и SetIm еще пересчитывают модуль числа (так просто в моей задаче гораздо повышается быстродействие, а она работает с большими массивами данных)

0

Сообщение от insideone Вообще говоря я прогонял некоторые stl вещи через пошаговый проход и это выглядело просто ужасно. В смысле можно час сидеть нажимать кнопку "следующая строчка" а в своем коде это реально видно что гораздо меньше. Это конечно не показатель, но все же выглядит подозрительно.

Неважно, сколько часов ты нажимал на кнопку "следующая строчка" для STL и для своего велосипеда. Данные профилировщика - где?

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

0