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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

http://unthought.net/c++/c_vs_c++.html (посмотрите на полпути вниз страницы или выполните текстовый поиск по термину «Совершенно другая разница! 567%», если хотите перейти к неожиданному фрагменту).

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

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

Answer 8

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

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

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