Почему объектно-ориентированное программирование провалилось?

Tiphon · 12-10-10 19:40:41

petrun пишет:

При определенных условиях.На определенных компиляторах.Много но)

Во первых давай вернемся из облаков теори-крафта на реальную землю. Под виндой это скорее всего будет VC, под линуксом gcc - если о С++ говорить, например. Это - раз.

Два - надо писать хороший код, а не ориентироваться по поводу компиляторов. Проблемы "сейчас" и даже 5-и лет назад, не говоря о 10-и - совсем разные. Тут речь идет о том, чтобы программист не парился по поводу того, во что превратит его код компилятор, и какие будут проблемы с оптимизацией его кода через 10 лет, а компилятор при этом работал хорошо требуя как можно меньше "искривления" дизайна. Это два. (да, С++ такими плюшками, например, почти не обладает)

petrun пишет:

Это как так?Механизм процесса ускорения в студию!

В студии.
Это три=)

pavel2403 · 12-10-10 19:59:00

petrun пишет:

А вызов класса что, бесплатен?

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

petrun пишет:

Не несите чушь.

Вобще-то, чушь здесь несешь один ты.

Mike22 · 12-10-10 20:06:49

DonDublon3 пишет:

А вообще - тут Майк22 первый начал, что объекты, якобы, замедлают программу, так что пусть он и обосновывает.

1. Создание и разрушение объектов - не мгновенная операция.
2. Расширение стандартных классов приводит к наследованию массы неиспользуемого функционала и переменных, что не оптимально.
3. Ухищрения, на которые идут ООП-программисты, когда им нужно сложное взаимодействие группы классов друг с другом (что в процедурном программировании без проблем делается глобальными переменными) невероятно запутывают и усложняют код, что негативно сказывается на быстродействии.

А теперь обоснуйте, как объекты НЕ замедляют программу.

Добавлено спустя 02 мин 38 с:

pavel2403 пишет:

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

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

pavel2403 · 12-10-10 20:52:35

Mike22 пишет:

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

Как это нет? в классе уже есть все что мне надо все свойства методы и события, а функции должны еще отработать. wink

Tiphon · 12-10-10 21:08:59

Mike22 пишет:

1. Создание и разрушение объектов - не мгновенная операция.
2. Расширение стандартных классов приводит к наследованию массы неиспользуемого функционала и переменных, что не оптимально.
3. Ухищрения, на которые идут ООП-программисты, когда им нужно сложное взаимодействие группы классов друг с другом (что в процедурном программировании без проблем делается глобальными переменными) невероятно запутывают и усложняют код, что негативно сказывается на быстродействии.

Ну, это ты пишешь про специфику С++. А С++ - вообще бяка. Но даже если говорить за него, то:
1) Создание и разрушение - не мгновенная операция. Так же, как и маллок в С. Так же как и вообще аллокейшн. Беда у твоего заявления в чем: ты имеешь ввиду скорее всего С++сный нью, который создает объект в куче. Беда в том, что ты, на самом деле, сам того не зная, говоришь не про ООП, а просто про проблему инициализации объектов в куче. И она не быстрая, тк.к. куча может быть (и обычно) фрагментирована. Поэтому умные люди, будь то С++ и С обычно выделают буферы в куче... В общем так, слово за слово, мы прийдем к менеджерам памяти))) Но ООП тут не сильно причем. Скорее только в том, что первые главы учебников учат new MyClass(), но человек не знает, что за этим стоит. Но это, прстити, называется быдлокодерством)

1б) Иногда С++ используют, как С только с конструкторами и деструкторами для "инициализации структур" - очень удобно. По словам этих же системщиков, накладных расходов на конструкторы и деструкторы тогда нет.

1в) Другое дело, когда создается виртуальная таблица для цепочки наследования. Но тут опять беда - ты пришился к С++, который в этом деле кривоват. Но в любом случае, можно это рассматривать не как ООП, а как некую парадигму, которую ты применяешь для собственного удобства. И накладные расходы на парадигму, которая применяется для удобства использоания. Но виртуальные таблицы совсем не обязятельно создавать, это вопрос скорее хранения класса в памяти. Если у тебя есть хитровыковыренный язык с нормальным менеджером памяти и JIT-ом, он может вполне себе делать то, о чем я писал выше (а ты ведь читал мой пост?)

2) Опять же ты говоришь за С++, а не все ООП. А С++ - это какашка. Если ты возмешь C#, то там будут расширения классов за счет extension methods (гугли), которые позволяют не городить С++ зоопарк расширений наследованием. Там где это не нужно, разумеется.

3) Пример можешь привести? Т.к. обычно такие ухищрения являются недостатком дизайна. То, что ты говоришь, как мне кажется, отлично вписывается в аспектно ориентированный подход (и я не видел, где бы он применялся в функциональных языках). Да и с глобальными переменными в ООП языках обычно проблем нет.

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

pavel2403 · 12-10-10 21:27:33

Tiphon пишет:

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

Ага, особенно когда каждую после использования нужно не забыть очистить и именно в нужный момент. Не проще ли
Set MyClass = Nothing? и все и никаких тебе забот с глобальными переменными.

Mike22 · 12-10-10 21:31:55

pavel2403 пишет:

Как это нет? в классе уже есть все что мне надо все свойства методы и события, а функции должны еще отработать.

Метод - суть та же функция. От того, что к нему обращаются так "someclass.someMethod()", а не "some_method()" - ничего в быстродействии не меняется.

Tiphon пишет:

Так же, как и маллок в С. Так же как и вообще аллокейшн.

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

Как пример, используя Sprite() в AS3 я получаю доступ к унаследованным 25 методам и 30 свойствам, включающими в себя работу с фокусом, получение/создание событий и даже работу со звуком (!). И все это ради одного спрайта, от которого мне может быть нужна только одна линия.

Sprite -> DisplayObjectContainer -> InteractiveObject -> DisplayObject -> EventDispatcher -> Object

И у меня нет возможности создать "такой же спрайт, но без маджонга и гейш", каждый спрайт обязательно будет инициализировать всю свою цветомузыку. Когда такой спрайт один - все нормально. А вот 40 тысяч уже вешают современный компьютер. Да первый пентиум без проблем мог работать с сорока тысячами картинок на экране.

Tiphon пишет:

Более того, вероятно ты, будучи веб программистом, не особенно задумываешься о многопоточности

Ну конечно не задумываюсь. У меня сейчас железка с 16 ядрами, к чему мне потоки? Пусть все на одном камне крутится в один поток, с целью неувеличения энтропии. А заказчику объясню, что 15 ядер - запасные.

Короче, меньше понтов пожалуйста. Это выглядит оскорбительно.

pavel2403 · 12-10-10 21:42:21

Mike22 пишет:

Метод - суть та же функция. От того, что к нему обращаются так "someclass.someMethod()", а не "some_method()" - ничего в быстродействии не меняется.

То есть??? Этим методом я получаю весь набор свойств класса, а что бы в обычном процедурном программировании мне их получить надо вызвать n-функций последовательно, что бы получить значение каждого свойства из набора, это же очевидно!

Добавлено спустя 02 мин 18 с:

Mike22 пишет:

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

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

Tiphon · 12-10-10 22:16:26

Mike22 пишет:

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

Эм... Ты мой пост прочитай внимательнее?

Tiphon пишет:

Если ты возмешь C#, то там будут расширения классов за счет extension methods (гугли), которые позволяют не городить С++ зоопарк расширений наследованием.

Mike22 пишет:

Короче, меньше понтов пожалуйста. Это выглядит оскорбительно.

Какие понты? Просто специфику знаю. А остальные 15 ядер обрабатывают остальные 1426 запросов от пользователей к серверу в данный момент.

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

Mike22 · 12-10-10 22:49:09

Tiphon пишет:

Если ты возмешь C#, то там будут расширения классов за счет extension methods (гугли), которые позволяют не городить С++ зоопарк расширений наследованием.

И что, extension methods как-то поможет базовым классам не инициализировать переменные? Создание расширения с парой новых методов - тоже не особо затратно, затратно именно создание базового класса с его линейкой наследования.

Tiphon пишет:

А остальные 15 ядер обрабатывают остальные 1426 запросов от пользователей к серверу в данный момент.

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

Tiphon · 12-10-10 23:08:11

Mike22 пишет:

И что, extension methods как-то поможет базовым классам не инициализировать переменные?

Ну да, если ты не создаешь линейку базовых классов.
А вообще давай подробнее, я не очень понимаю твой claim.

Например Sprite -> DisplayObjectContainer -> InteractiveObject -> DisplayObject -> EventDispatcher -> Object - ради одного спрайта... Значит, что либо архитектура хреновая (чем славился ак, правда 3-й, говорят, хорошо допилили, но я его уже не видел). Либо это оправдано.

Если брать .NET базовые библиотеки, то там такого обычно нет или, если есть, то для этого есть оправдание.

На то, что ты приводишь где-то у тебя архитектура плохая, я тебе тоже сказать могу, что тут разбирать иногда приходится алгоритмы на фортране 77, там черт ногу в гото сломит, а еще длинна строки ограничена, поэтому все меременные называются а1, б2, а еще мудак, который это писал комментариев не делал в принципе. Что, теперь все функциональные языки говно?

-------------------------------------------------------------------------------------

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

Вопрос, как этого добиться? .so .dll библиотеки? - отпратительно. Однако в .NET можно использовать и F#, и C# в одном флаконе запросто. Туда можно намного проще запихать C/C++ (чем юзать через длл/со), который (правда под виндой, вот беда) обладая и прямым управлением памятью и менеджером памяти с JIT по тестам рвет анменеджед (обычный) С/С++. Ну и питон с руби тоже там. Ответной технологии в полном весе в линуксе сейчас нет.

Mike22 · 12-10-10 23:40:18

Tiphon пишет:

А вообще давай подробнее

Вне зависимости от методов наследования базовые классы содержат множество как public, так и private переменных, а зачастую и громоздкие процедуры инициализации. В функциональном программировании стандартные библиотеки, как правило, содержат лишь функции для обработки данных, а инициализация остается на выбор программиста. В том же примере со Sprite - не нужно было бы хранить scaleX, scaleY, scale9grid и transform - это было бы проблемой программиста, а в библиотеке была бы функция scale(source, x, y, grid). Если программисту не нужно помнить значение последнего преобразования scale - он бы его и не хранил.

Tiphon пишет:

для этого есть оправдание

Конечно есть. Это увеличивает скорость разработки. Оперирую ли я с Bitmap, Sprite или MovieClip - я знаю, что все они унаследовали масштабирование, повороты, прозрачности, массив фильтров и многое другое от DisplayObject. Единообразие - ключ к упрощению и пониманию. Но цена за это - неэффективная трата памяти и процессорного времени. И чем выше уровень наследования, тем больше не нужного для конкретной задачи мусора тянется в код.

Когда-то меня очень удивил Delphi - простейшая форма с кнопкой потребовала полумегабайтного исполняемого файла. Некоторые кейгены умудряются сделать это же за 5 килобайт. Разница в сотни раз.

Гареев Станислав · 12-10-10 23:58:38

Mike22 пишет:

1. Создание и разрушение объектов - не мгновенная операция.

Создание да.
Прокомментирую ИМХО.
Объект перестаёт существовать с исчезновением последней ссылки на него (данный процесс контролирует счётчик ссылок), однако событие terminate является часто именно тем накладным расходом которое хотелось бы урезать. Если же объект имеет множество вложенных объектов, то при его инициализации и уничтожении будут также создаваться и уничтожаться вложенные в него объекты.

Цитата из книги по VB 6.0 : "Дети, не пытайтесь сделать это дома. Связанные при помощи событий динозавры станут настолько медлительны что просто вымрут."

Mike22 · 13-10-10 00:09:57

Гареев Станислав пишет:

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

Поэтому, для части объектов я регулярно форсирую повторное использование. Для этого приходится писать так, чтобы создание функций reinit() и update() не было проблемой, но оно себя окупает. Особенно в AS3 отличающимся особо тупым GC.

pavel2403 · 13-10-10 00:12:25

Гареев Станислав пишет:

Цитата из книги по VB 6.0 : "Дети, не пытайтесь сделать это дома. Связанные при помощи событий динозавры станут настолько медлительны что просто вымрут."

А ты внимательно прочел эту книгу??? А там ведь для детей написано, что VB 6 не содержит автоматического сборщика мусора, потому как VB6 это все таки язык со смешанной парадигмой, то есть там можео использовать как процедурный подход так и ООП. Так вот, дети, если вы где-то сделали Set myClass = New Class , то по оканчании работы с ним, не забудьте сделать Set myClass = Nothing. А то после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать или зависнуть намертво и вам придется делать ребут. big_smile

bALMER · 13-10-10 01:06:22

Armanx64 пишет:

На мой взгляд, Делфи - это огроменный прорыв вперёд.

lol lol lol lol lol

Добавлено спустя 01 мин 08 с:

pavel2403 пишет:

А то после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать или зависнуть намертво и вам придется делать ребут. big_smile

Открыт секрет глючности винды)) Спасибо Павел!

Mike22 · 13-10-10 02:15:36

pavel2403 пишет:

А то после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать или зависнуть намертво

Я не понял, это что, утверждение, что в винде настолько хреновый менеджер процессов, что он даже не способен очистить память после окончания работы приложения и приложение само обязано заботиться о том, чтобы завершиться "чисто"?

Linfan · 13-10-10 02:25:19

pavel2403 пишет:

А то после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать или зависнуть намертво и вам придется делать ребут.

Пашок, че-то ты откровенную херню спорол. После завершения процесса, аллокированная память освобождается. Или может в венде это новое веяние моды? lol

Добавлено спустя 1 ч 36 мин 40 с:

pavel2403 пишет:

А там ведь для детей написано, что VB 6 не содержит автоматического сборщика мусора, потому как VB6 это все таки язык со смешанной парадигмой, то есть там можео использовать как процедурный подход так и ООП.

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

shell32 · 13-10-10 05:27:05

Mike22 пишет:

Когда-то меня очень удивил Delphi - простейшая форма с кнопкой потребовала полумегабайтного исполняемого файла. Некоторые кейгены умудряются сделать это же за 5 килобайт. Разница в сотни раз.

потому что в классе TForm реализовано всё что только могло быть реализовано, например есть обработчики всех системных сообщений которые могут быть им обработаны.
можешь показать кейген в 5 килобайт умеющий то же самое?
но если это не нужно - Delphi никак не ограничивает программиста в написании собственного класса, аналогичного TForm, но не имеющего ничего "лишнего", или использовании WinAPI

Linfan · 13-10-10 06:09:52

shell32 пишет:

можешь показать кейген в 5 килобайт умеющий то же самое?

Лехко! lol Посмотри, че за либы кейген импортит. Экзешник может и 5 кил, но за ним лезет в память несколько мегабайт длл'ек. По сути, в кейгене логики с гулькин нос и только макет формочки. Все барахло в VS рантаймах.

pavel2403 · 13-10-10 07:55:15

Mike22 пишет:

Я не понял, это что, утверждение, что в винде настолько хреновый менеджер процессов, что он даже не способен очистить память после окончания работы приложения и приложение само обязано заботиться о том, чтобы завершиться "чисто"?

Кто говорил об окончании??? Один и тот же обьект может инциализироваться в приложении сколько угодно раз. )

Linfan пишет:

Пашок, че-то ты откровенную херню спорол. После завершения процесса, аллокированная память освобождается. Или может в венде это новое веяние моды?

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

Linfan пишет:

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

Ну может припомним когда появился VB6 и питон, в том виде о котором ты сейчас заявляешь??? wink
Для тех кто не понял о чем я говорю: ru.wikipedia.org/wiki/%D0%A3%D1%82%D0%B … 1%82%D0%B8

Отредактировано pavel2403 (13-10-10 08:24:10)

Tiphon · 13-10-10 08:06:05

Mike22, Есть 2 больших "но". Во-первых ты мне продолжаешь тыкать пример "не лучшей" архитектуры. Повторюсь, что тут разбирать иногда приходится алгоритмы на фортране 77, там черт ногу в гото сломит, а еще длинна строки ограничена, поэтому все переменные называются а1, b2, ij, а еще мудак, который это писал комментариев не делал в принципе. Что, теперь все функциональные языки говно?

Во-вторых ты говоришь о тяготах ООП языков, как будто на дворе 88-й год. Уже давно и в менеджерах памяти операция "создания" может не являться критической по времени, наоборот, является быстрой, и отложенная инициализация, и компановка классов, и jit и куча других наворотов, о которых программист может спокойно себе не знать=) Но да, не везде это доступно. Да, С++ ближе к 88-му, чем некоторые другие языки.

shell32 · 13-10-10 11:32:44

Linfan пишет:

Посмотри, че за либы кейген импортит.

это не тот случай, но если говорить о импорте, то с BPL или KOL и Delphi даст примерно тот же результат:

Linfan пишет:

Экзешник может и 5 кил, но за ним лезет в память несколько мегабайт длл'ек.

Гареев Станислав · 13-10-10 15:52:06

bALMER пишет:

Открыт секрет глючности винды)) Спасибо Павел!

Пашок не совсем понял что сам сказал.

Павел, это в вашем c++ бывают утечки памяти. Не критикую, просто скорость требует меньшего количества накладных расходов и больший профессионализм. Обычно я прикреплял объекты в виде закрытых/открытых свойств формы, и вы должны знать что при выгрузке последней формы и окончании выполнения всего кода приложение является завершённым. То что вы описали скорее всего может происходить в случае применения оператора END. Хотя я и в этом сомневаюсь, потому что ОС получив от программы сигнал завершения должна перестать выделять ей процессорное время и очистить выделенные программе страницы памяти.
Мне так во всяком случае кажется.

Касаемо книжки, прочитал за 3 дня (иногда на скорочтение переходил). Страниц немного 956 считая предметный указатель.

petrun · 13-10-10 16:40:38

Tiphon пишет:

На то, что ты приводишь где-то у тебя архитектура плохая, я тебе тоже сказать могу, что тут разбирать иногда приходится алгоритмы на фортране 77, там черт ногу в гото сломит, а еще длинна строки ограничена, поэтому все меременные называются а1, б2, а еще мудак, который это писал комментариев не делал в принципе. Что, теперь все функциональные языки говно?

Погодите, погодите.Это с какого перепугу фортан - функциональный язык?

Форум StopLinux

Объявление

#26 12-10-10 19:40:41

Re: Почему объектно-ориентированное программирование провалилось?

#27 12-10-10 19:59:00

Re: Почему объектно-ориентированное программирование провалилось?

#28 12-10-10 20:06:49

Re: Почему объектно-ориентированное программирование провалилось?

#29 12-10-10 20:52:35

Re: Почему объектно-ориентированное программирование провалилось?

#30 12-10-10 21:08:59

Re: Почему объектно-ориентированное программирование провалилось?

#31 12-10-10 21:27:33

Re: Почему объектно-ориентированное программирование провалилось?

#32 12-10-10 21:31:55

Re: Почему объектно-ориентированное программирование провалилось?

#33 12-10-10 21:42:21

Re: Почему объектно-ориентированное программирование провалилось?

#34 12-10-10 22:16:26

Re: Почему объектно-ориентированное программирование провалилось?

#35 12-10-10 22:49:09

Re: Почему объектно-ориентированное программирование провалилось?

#36 12-10-10 23:08:11

Re: Почему объектно-ориентированное программирование провалилось?

#37 12-10-10 23:40:18

Re: Почему объектно-ориентированное программирование провалилось?

#38 12-10-10 23:58:38

Re: Почему объектно-ориентированное программирование провалилось?

#39 13-10-10 00:09:57

Re: Почему объектно-ориентированное программирование провалилось?

#40 13-10-10 00:12:25

Re: Почему объектно-ориентированное программирование провалилось?

#41 13-10-10 01:06:22

Re: Почему объектно-ориентированное программирование провалилось?

#42 13-10-10 02:15:36

Re: Почему объектно-ориентированное программирование провалилось?

#43 13-10-10 02:25:19

Re: Почему объектно-ориентированное программирование провалилось?

#44 13-10-10 05:27:05

Re: Почему объектно-ориентированное программирование провалилось?

#45 13-10-10 06:09:52

Re: Почему объектно-ориентированное программирование провалилось?

#46 13-10-10 07:55:15

Re: Почему объектно-ориентированное программирование провалилось?

#47 13-10-10 08:06:05

Re: Почему объектно-ориентированное программирование провалилось?

#48 13-10-10 11:32:44

Re: Почему объектно-ориентированное программирование провалилось?

#49 13-10-10 15:52:06

Re: Почему объектно-ориентированное программирование провалилось?

#50 13-10-10 16:40:38

Re: Почему объектно-ориентированное программирование провалилось?

Подвал форума