Вопросы для начинающих ООП

Я просто хочу задать два быстрых вопроса об ООП.

Во-первых, действительно ли код, созданный компилятором языка OOP, отличается от компилятора процедурного языка? Я имею в виду, что ООП только о том, как вы пишете код, или это действительно скомпилированный код, отличный от процедурного? Более точные, процедурные языки, такие как C, в основном производят такой код, как это было бы написано в ASM. Но код ООП отличается от других?

И во-вторых, если код ООП использует другой подход в своей машинной форме кода, он медленнее или быстрее процедурного? Спасибо.

Ответ 1

Во-первых, нет. Для языков, которые скомпилированы в собственный машинный код, это, безусловно, так. В конце концов, сборка и машинный код не имеют понятия объектов.

Для языков, работающих на виртуальной машине, например Java или С#, это отчасти верно. Здесь VM может поддерживать некоторые специфичные для объекта функции.

Можно писать ООП в не-объектно-ориентированных языках, а наоборот. ООП в основном полезен для программиста, и ограничения, которые он налагает (например, вы не можете получить доступ к приватным методам из другого класса, например), проверяются компилятором, но не передаются на выходе.

Во-вторых, нет разницы в производительности для ООП или процедурного. Просто код и данные находятся в разных местах кода.

Ответ 2

Это сильно зависит от фактического алгоритма, который вы пытаетесь реализовать, и от компилятора (в последние годы они стали очень умными). Скомпилированный код определенно не будет байтовым для байтов идентичным, и он может быть даже совершенно другим (опять же, зависит от алгоритма, который вы реализуете). В действительности это не имеет значения.

В большинстве случаев разница в скорости программы будет незначительной - если вы не делаете что-то крайне неэффективное в той или иной форме (и это будет скорее всего связано с вашей бизнес-логикой и алгоритмами, которые вы будете использовать для его реализации, а не для парадигмы программирования), это не будет проблемой.

Другая, часто забываемая, но решающая разница в скорости заключается в ремонтопригодности: компьютерное время в большинстве случаев дешево; Время программиста дорого. (Чтобы не сказать "написать bloatware", а скорее "не тратьте деньги на неделю, выясняя, как это работает, когда кому-то еще нужно обновить логику, через три года" )

Ответ 3

Все языки производят один и тот же код, например ASM (машинный код), кроме языков, которые создают байт-код (например: Java) или интерпретируемые языки (например, Python, PHP)

Ответ 4

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

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

В основном, моя точка зрения заключается в следующем: выигрыш от кода, который легче читать, повторно использовать и поддерживать, может легко оправдать небольшую потерю производительности (если таковая имеется), большую часть времени.

Ответ 5

Весь код в конечном итоге сводится к машинным кодам. Есть только определенные способы представления данных в памяти. Я бы предположил, что код ASM полностью зависит от компилятора, и если вы выполняете оптимизацию. Для файлов, скомпилированных в байтовом коде, источник скомпилируется в байт-код, а затем запускается через интерпретатор. Может быть даже компилятор JIT (Just-In-Time), который компилирует этот байт-код в собственный машинный код.

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

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

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

Ответ 6

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

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

Ответ 7

Всегда существует некоторый компромисс между эффективностью и ремонтопригодностью.

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

В конце концов, OOP или нет, встроенные компиляторы будут генерировать код ASM, или VM будет генерировать байт-коды (для JIT-компиляторов). Важно не смешивать парадигму ООП с скомпилированным кодом; компьютеру все равно, как организован код и будет его исполнять точно так же. Конечно, процедурный код будет отличаться от ООП, который был скомпилирован. Однако я не стал бы говорить о том, что ООП просто "о том, как вы пишете код", просто потому, что производительность процедурного приложения всегда будет идти быстрее вниз по мере расширения проекта, чем ООП.

Ответ 8

Фактически, обычно объектно-ориентированный код приведет к чему-то (очень) немного медленнее. Причина этого в том, что объекты и классы имеют накладные расходы - хотя фактический код становится процедурным, в фоновом режиме все еще происходит "материал". Хорошее сравнение C и С++ можно найти здесь:

http://unthought.net/c++/c_vs_c++.html (посмотрите примерно на половину пути вниз по странице или выполните текстовый поиск по термину "Вполне разница!" % ", если вы хотите перейти на удивительный бит).

Это немного старый, но все же очень действительный. Однако в большинстве случаев ускорение скорости не стоит дополнительного времени, необходимого для написания кода - это действительно экстремальный пример, и помните, что C - очень низкоуровневый язык; на самом деле, я не знаю, что у меня на голове какой-либо другой язык, который будет бить С++ так всесторонне в прямом тесте скорости.

Также обратите внимание, что плохо написанный процедурный код почти всегда будет медленнее, чем хорошо написанный OO-код (я думаю, кто-то уже упомянул об этом).