ООП, за, за и против

Список форумов Общий раздел Программирование

Описание: Обучение программированию, интересные задачи, полезные ресурсы

  • 1

#1 RomanF » 27.08.2013, 18:24

Всем привет,
кто знает что такое ООП, не находили ли вы минусов в данном подходе?
Лично я очень впечатлен насколько быстро можно разрабатывать приложения, используя ООП, но есть одна ложка дегтя :) Быстрая разработка почти всегда означает низкую производительность.

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

Есть ли у вас свои секреты оптимизации ООП кода? Знаете ли вы другие недостатки ООП?
RomanF
Репутация: 14

#2 Cамурай » 27.08.2013, 18:33

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

Для ускорения работы можно профилировать приложение на этапе исполнения и выявить узкие места, которые затем подвергнуть оптимизации.
Cамурай
Аватара
Откуда: Р/н/Д
Репутация: 32

#3 RomanF » 30.08.2013, 09:26

Расшифрую свой вопрос:
Предположим в базе хранятся виртуальные животные, которые в приложении описаны классом animal
у класса animal есть метод feed (покормить)
Подход ООП состоит в том, что если мы хотим покормить всех животных, то:
foreach(currentAnimal in Animal.AllAnimals)
{
currentAnimal.Feed();//Здесь будет БД дергаться, либо потом дин раз дернется с огромным количеством параметров (тут еще у SQL есть ограничения по количеству параметров, так что не всё так просто в ООП)
}

Процедурное мышление даст нам:
db.Execute("update animals set feedPercent=100");

Абсолютно очевидно, что при программировании ООП в лоб, приложение проиграет процедурному подходу в производительности из-за самой концепции ООП.

Вопрос именно в том, как вы увеличиваете производительность концептуальную не изменив принципам ООП
RomanF
Репутация: 14

  • 1

#4 Pentium133 » 30.08.2013, 13:08

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

Всему своё место. Способ реализации нужно выбирать в зависимости от задачи.

В общем случае, ООП-подход увеличивает скорость выполнения, требования к памяти и процессору, но уменьшает время разработки и упрощает поддержку, что по финансам значительно выгоднее.
Pentium133
Аватара
Репутация: 12

#5 Pentium133 » 30.08.2013, 14:15

поправка «В общем случае, ООП-подход уменьшает скорость выполнения, и увеличивает требования ....»
Pentium133
Аватара
Репутация: 12

#6 RomanF » 30.08.2013, 14:31

Да, все правильно, метод Animal.FeedAll убьет Всю концепцию ООП, ибо отвалится, как только метод Feed будет переделан :)
RomanF
Репутация: 14

#7 Cамурай » 30.08.2013, 14:59

Нужно определиться, шашечки или ехать. Давай всё писать с процедурным подходом без использования ООП :) Думаю, что надолго энтузиазма не хватит.
Согласен с Pentium133 насчет комбинированного подхода именно ради оптимизации. Если важно строгое следование концепции, то зачем тогда вести речь о скорости?
Cамурай
Аватара
Откуда: Р/н/Д
Репутация: 32

#8 RomanF » 30.08.2013, 17:54

собственно вопрос в том, существуют ли в такие моменты "красивые" выходы из ситуации или все "разбавляют"
RomanF
Репутация: 14

#9 Cамурай » 08.10.2013, 22:34

Подходящей темы не нашел, поэтому тут.

$this->bbcode_second_pass_url('http://hackertyper.com/', 'Текстовый редактор для программирования.') :D
Cамурай
Аватара
Откуда: Р/н/Д
Репутация: 32

#10 alman » 26.11.2013, 23:06

Ну, я могу сказать только за С++.

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

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

$this->bbcode_second_pass_code('', '
MyClass objects_array[1024];
')
Похоже, конструктор вызовется 1024 раза. А это уже может оказаться чувствительно для производительности.

Если не забывать об этих фичах, то можно использовать их по необходимости, оптимально и даже с некоторым выигрышем. В остальном всё то же самое, что и в классическом Си.

Ничего не могу сказать за STL, но почему-то все без ума от неё. Наверное, в этом что-то есть.

А-а-а. Вот! Вспомнил. Можно сильно уронить производительность, если полагаться на исключения. Я склоняюсь к выводу, что во многих слчаях оптимальнее сделать дополнительную проверку и вернуть код ошибки, чем полагаться на исключения.
alman
Репутация: 4

#11 RomanF » 27.11.2013, 13:47

Хорошие советы :-) Про исключения вообще больная тема в C# например. Производительность падать может в десятки раз.
STL, кстати, очень удобен, но как-то с выделением памяти у него проблемы :(
RomanF
Репутация: 14

  • 1

#12 master » 02.07.2014, 17:59

Вы в каком веке живете товарищи? ))

$this->bbcode_second_pass_code('', '
public static void main(String[] args) {

int count = 0;
long st = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
try {
throw new Exception("wejfvqnierj");
} catch (Exception e) {
count++;
}
}
long fin = System.currentTimeMillis();
System.out.println(fin - st + " : " + count);
}
')результат 655 : 1000000. 1 млн исключений генерируется чуток более чем пол секунды!
master
Аватара
Репутация: 1

#13 Cамурай » 04.07.2014, 12:45

$this->bbcode_second_pass_quote('master', '')ы в каком веке живете товарищи? ))
Оптимизация будет актуальна всегда. Есть разные задачи, разные среды исполнения.
Cамурай
Аватара
Откуда: Р/н/Д
Репутация: 32

#14 master » 09.07.2014, 15:46

$this->bbcode_second_pass_quote('Cамурай', '')птимизация будет актуальна всегда. Есть разные задачи, разные среды исполнения.

Вне всякого сомнения, если есть возможность не брость исключение (проверить на null etc) то бросать его не следует.
Но и усложнять код путем ввода, скажем, кода результата операции не следует. Все зависит от конкретной задачи.
master
Аватара
Репутация: 1

#15 RomanF » 14.07.2014, 11:59

master, лучше поделитесь мыслями насчет компромиссов ООП-костыли :)
RomanF
Репутация: 14

#16 master » 14.07.2014, 18:59

Какие такие костыли?
Совсем не испытыю сложности с использованием ООП. Если говорить про наследевание и переопределение реализации метода то место входа в метод вычисляется статичиски на этапе компилаяции (в большенстве случаев). Расходы минимальны.
Оптимизация, если она необходима, делается используя нарушения нормального подхода написания кода (длинные методы и т.д.).
Но, мест где нужно оптимизировать код не так много. Как правило это работа с базой или сетью, IO одним словом. Это для сурового продакшина :)
master
Аватара
Репутация: 1

#17 master » 14.07.2014, 19:02

Единственно заимствывание в ООП без которого было тяжко это функцианальный подход.
В C# уже давно есть LINQ, да и правильном языке Java тоже появились с 8-й версии.
Кто на С++ - сам себе злой буратино :)
master
Аватара
Репутация: 1


Вернуться в Программирование

Кто сейчас на сайте (по активности за 60 минут)

Сейчас этот форум просматривают: 2 гостя