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