не совсем. вы забываете, что у наследования в объектно-ориентированной модели больше свойств, чем просто абстрактность и упрощение.
многократно упоминавшийся полиморфизм, который действительно работает (скажем, делали мы ПакМан на объектном Си - так у нас можно было легко изменять логику игры, вставлять новых монстров и прочее-прочее, что при процедурном подходе выливалось бы в головную боль), области видимости переменных (надеюсь, знаете, о чем речь), множественное наследование и многое-многое другое.
а вот выбрать тот уровень абстракции, на который надо ориентироваться, - это основная задача программиста. на примере:
если вам нужен стол как просто объект интерьера - то, пожалуйста, реализуйте его как единый объект. а вот если вы делаете реальную физ.модель, где этот стол разносит на куски, то, возможно, придется делать более сложную модель.
вот одно из главных преимуществ ООП - масштабируемость. я могу и планету делать одним обхектом, а могу считать каждую песчинку - в зависимости от модели.
а процедурный подход предполагает более или менее однородную структуру программы, которая реализует более или менее линейный процесс.
но все же скорость остается главной проблемой ООП - это как отличие в скорости между интерпретатором и компилятором. или, к примеру, эмуляцией процесса и исполнением его на машинном коде.
самый яркий пример - DosBOX, на котором некоторые игры умудряются тормозить. или запуск Винды под вайном.
это примерно как сайт сделать одной страничкой, "разбавив" заголовками (типа, можете найти информацию сами, используя поиск в браузере). во многих случаях, так оно, конечно, так, но когда разработкой занимается команда или проект планирует перерасти из небольшой в монстра (как справедливо уже замечено про Вордпресс тот же), то отслеживать все это становится все сложнее и сложнее. то же с повторным использованием кода - к примеру, полиморфизм при процедурном подходе реализуется муторно и криво.
а насчет инкапсуляции - видимо, еще не сталкивались с такими понятиями, как бизнес-логика и разработка библиотек для сторонних разработчиков...
ну, я где-то читал, что до выравнивания еще далеко - рынку далеко до пресыщения. к примеру, только у нас в регионе действует 5 международных (как они ся называют :) организаций, которые берут в штат программистов и натаскивают их на Java, чтобы создать тимы для разработки кучи всяких продуктов и поддержки САПы... и они все расширяются и расширяются.
почему нет? то, что он тянет другие, конечно, сыграет роль на скорости исполнения, но с другой стороны - облегчит структуру кода, возможность повторного использования, а также при правильной разработке инкапсулирует бизнес-логику. что еще надо от ООП?
вообще-то, довольно легко на пальцах показать, что использование ООП убыстрить программу не может.
почему? создание объекта через конструкторы, которые могут наследоваться, использование вместо простых переменных более сложных структур. тот же полиморфизм, когда компилятор должен решить, какой из наследуемых методов должен быть запущен. в Java, кстати, для деструкции объектов есть "сборщик мусора", он дополнительно мониторит область памяти и удаляет ставшие ненужными.
ООП не быстрее, ООП удобнее. с другой стороны, оптимизируя реализацию ООП разработчики добиваются того, что эта "удобность" становится достаточно быстрой.
это всего лишь эвфемизм, который заменил более смачное ругательство - потому как подобный непрофессионализм встречается все чаще и чаще, и при этом айтешнеги, как они себя называют, начитавшись баша, еще считают себя самыми крутыми и умными, не зная даже азов...
наследование, вообще-то, один из ключевых понятий ООП, как раз после абстракции, о которой только что сказали вы.
а вообще, правильнее, будет сделать высоту так:
class obj
{
private int height;
public int getHeight()
{
return this->height;
}
}
почему надо скрывать переменную и использовать метод? потому что, если height сменится с целочисленного на вещественный, то придется учитывать возможности ошибок во всех местах программы. а так - мы используем метод getHeight(), в котором вся реализация инкапсулирована внутри.
>Там где явно выделяются процессы, процедруный подход.
совсем не факт - ООП применяется не там, где есть объекты, а там, где предметная область может быть представлена в виде объектов и это будет, как говорится, хорошо )
"радовать", "комедия"... я, конечно, понимаю, что можно с открытыми ртами ходить по два раза на каких-нибудь спартанцев, или называть аншлаг юмористическим, но от тошниловки Уве Болла, простите, тошнить хочется. даже не смешно.
вы не понимаете - Уве Болл не просто снимает/продюсирует плохие фильмы. специально закупается лицензия на кинопостановку игры, а это значит, что ХОРОШЕГО ФИЛЬМА ПО ХОРОШЕЙ ИГРЕ ПОСЛЕ ЭТОГО УВИДЕТЬ БУДЕТ НЕВОЗМОЖНО. вот и все.
закономерности природы зачастую так строго математичны, что приводят в шок.
многократно упоминавшийся полиморфизм, который действительно работает (скажем, делали мы ПакМан на объектном Си - так у нас можно было легко изменять логику игры, вставлять новых монстров и прочее-прочее, что при процедурном подходе выливалось бы в головную боль), области видимости переменных (надеюсь, знаете, о чем речь), множественное наследование и многое-многое другое.
а вот выбрать тот уровень абстракции, на который надо ориентироваться, - это основная задача программиста. на примере:
если вам нужен стол как просто объект интерьера - то, пожалуйста, реализуйте его как единый объект. а вот если вы делаете реальную физ.модель, где этот стол разносит на куски, то, возможно, придется делать более сложную модель.
вот одно из главных преимуществ ООП - масштабируемость. я могу и планету делать одним обхектом, а могу считать каждую песчинку - в зависимости от модели.
а процедурный подход предполагает более или менее однородную структуру программы, которая реализует более или менее линейный процесс.
но все же скорость остается главной проблемой ООП - это как отличие в скорости между интерпретатором и компилятором. или, к примеру, эмуляцией процесса и исполнением его на машинном коде.
самый яркий пример - DosBOX, на котором некоторые игры умудряются тормозить. или запуск Винды под вайном.
а насчет инкапсуляции - видимо, еще не сталкивались с такими понятиями, как бизнес-логика и разработка библиотек для сторонних разработчиков...
вообще, где-то в 60% случаев, если можно обойтись без наследования, то использование ООП - изыбточно.
почему? создание объекта через конструкторы, которые могут наследоваться, использование вместо простых переменных более сложных структур. тот же полиморфизм, когда компилятор должен решить, какой из наследуемых методов должен быть запущен. в Java, кстати, для деструкции объектов есть "сборщик мусора", он дополнительно мониторит область памяти и удаляет ставшие ненужными.
ООП не быстрее, ООП удобнее. с другой стороны, оптимизируя реализацию ООП разработчики добиваются того, что эта "удобность" становится достаточно быстрой.
а вообще, правильнее, будет сделать высоту так:
class obj
{
private int height;
public int getHeight()
{
return this->height;
}
}
почему надо скрывать переменную и использовать метод? потому что, если height сменится с целочисленного на вещественный, то придется учитывать возможности ошибок во всех местах программы. а так - мы используем метод getHeight(), в котором вся реализация инкапсулирована внутри.
совсем не факт - ООП применяется не там, где есть объекты, а там, где предметная область может быть представлена в виде объектов и это будет, как говорится, хорошо )