Существует проект, написанный на PHP, который просто просто процедурный … шаг за шагом вызывает функции БД, обработку и распечатку вывода. И затем он изменен на полностью объектно-ориентированный – для объекта App есть одноэлемент, а через объект App вызывается различные функции.
Кто-то утверждает, что использование памяти или след на сервере будет меньше. Так будет? Я думал, что процедурный часто просто использует минимальный минимальный уровень, в то время как объектно-ориентированное программирование с различными шаблонами дизайна обычно создает больше вещей, чем нужно, или просто имеет объекты, в то время как процедуры обычно имеют минимальный минимальный размер.
Так изменится ли весь код на объектно-ориентированный, что уменьшит использование памяти на сервере?
Вероятно, это будет больше, но сказать невозможно. Если ваш код действительно улучшается, делая это способом ООП, тогда это может быть меньше. Прямой корреляции между используемой памятью и наличием объектно-ориентированной не существует. Возможно, в целом объектно-ориентированная память занимает больше памяти, но только если оба набора кода написаны одинаково хорошо, и это почти никогда не бывает.
Есть ли причина, по которой это приложение обновляется до объективной ориентации? Вы знаете, что это не тот или другой, вы можете смешивать и комбинировать предметы … ООП не является серебряной пулей.
К сожалению, я тоже сделал свои тесты. Я тестировал скорость, и это примерно то же самое, но при тестировании на использование памяти, получающей memory_get_usage () в PHP, я видел на стороне ООП более большое число.
116,576 байт для ООП до 18 856 байт для процедурного. Я знаю, что «Оборудование дешево», но давай! Увеличение использования на 1000%? Извините, это не оптимально. И имея так много пользователей, поражающих ваш сайт сразу, я уверен, что ваша оперативная память просто сгорит или закончится. Я ошибаюсь?
В основном, то, что я слышу от всех моих поклонников ООП, заключается в том, что … Вы будете использовать больше ресурсов, это будет так же быстро, как и письменные процедурные вызовы функций, но это будет лучше для больших проектов и среды с несколькими разработчиками. Необходимо найти баланс.
Больше разработчиков (sloppy devs) и более крупный сайт
Con: Больше оперативной памяти, используемой для вашего приложения.
Pro: проще поддерживать код среди многих приложений.
Один разработчик с простым сайтом
Con: Если ваш сайт растет или начинает включать многих разработчиков, разработка может быть немного медленнее, если ваш процедурный код отстой.
Pro: Низкая ОЗУ, немного более высокая скорость. Если ваш код написан правильно (и только хорошие разработчики могут это сделать – ха-ха), ваш код будет таким же простым в обслуживании.
В ОЗУ войн выигрывает процедура. В войнах, связанных с ремонтопригодностью, выигрывает хороший кодекс. 😉
ООП-вентиляторы говорят, что ООП чище. Я видел некоторый действительно беспорядочный код ООП, а затем я видел некоторый процедурный код REALLY CLEAN, написанный разработчиками, которые могли писать отличный код на любом языке или в стиле. Код, с которым было приятно работать. Суть в том, что если у вас есть неаккуратные разработчики, неважно, какой стиль вы используете, у вас будет неаккуратный код.
Из-за моих собственных личных тестов я отказываюсь от ООП в памяти, главным образом потому, что я действительно сочиняю действительно чисто процедурный, и я, как правило, единственный разработчик в любом из моих проектов.
Ура!
Ваш вопрос звучит так для меня: у нас есть незаменимая кодовая база, будет ли переписывать ее на Java быстрее?
Во-первых, вам нужно определить проблему: ваш код нечитабельный и / или трудноподдерживаемый, или слишком высока область выполнения вашей программы? Это две совершенно разные проблемы.
Если у вас есть база кода, которую сложно поддерживать (это звучит так, как вы), вы не решите это, переписав код с помощью другой парадигмы. Почему код не читается? Разрабатывают ли разработчики нечитаемый код, а затем переписывают его на Java или C #, просто дают вам объектно-ориентированный нечитаемый код. В этом случае вам необходимо улучшить навыки ваших разработчиков (нанять лучших, перевоспитать существующие и т. Д.).
Если у вас возникла проблема с объемом памяти, вы должны подходить к ней как к любой другой проблеме с производительностью. Сначала измерьте , затем выполните некоторую оптимизацию (перепишите часть кода, чтобы сделать ее более эффективной с точки зрения памяти), а затем снова измерьте . Измерение до и после важно, чтобы убедиться, что вы не ухудшаете ситуацию. И поверьте мне, даже очень хорошие кодеры совершают эту ошибку.
Ответ – да и нет.
Перейдя на более объектно-ориентированную архитектуру, вы можете уменьшить объем памяти, но тогда и только тогда, когда код более эффективен.
Прямой PHP без каких-либо вызовов функций или вызовов объектов довольно быстро. Как только вы начинаете делать вызовы функций или вызовы объектов, вещи начинают идти намного медленнее.
От A Python против Ruby Vs. Python Benchmark стратегия OO для выполнения инкрементного цикла заняла 3,7079 секунды, ориентированная на функцию заняла 4,3501 секунды, а использование не заняло 0,6164 секунды. Выполнение простого приложения «Hello World» с OO и процедурным Vs. Ни у кого не было 4.1248 секунды против 3.7656 против 0.9309 секунд.
Таким образом, в зависимости от того, что делает ваш код и как он это делает, объекты могут быть как быстрее, так и медленнее, с большей интенсивностью памяти или с меньшей интенсивностью памяти, или ни с одним из них.
И затем он изменен на полностью объектно-ориентированный – для объекта App есть одноэлемент, а через объект App вызывается различные функции.
Это на самом деле похоже на нечто противоположное «полностью объектно-ориентированное». Это указывает на уровень понимания того, что означает «объектно-ориентированное», что, скорее всего, НЕ приведет к уменьшению объема памяти.
В целом дизайн будет иметь гораздо большее влияние на объем памяти, чем парадигма программирования, хотя, вероятно, верно, что в среднем объектно-ориентированные приложения имеют больший след.
Использование памяти не является преимуществом OO. Преимущество OO заключается в том, что код станет более ремонтопригодным. Если у вас нет проблем с производительностью, нет необходимости искать способы быть более эффективными.
В дополнение к другим комментариям я хотел бы сказать, что OO помогает сократить избыточность … что может сделать ваш код более эффективным и уменьшить объем памяти. Конечно, OO имеет больше накладных расходов, но должна работать более эффективно в крупных проектах.