Изменит ли весь код объектно-ориентированное использование памяти больше или меньше?

Question

Существует проект, написанный на PHP, который просто является процедурным ... шаг за шагом, вызывая функции БД, обрабатывая и распечатывая выходные данные. А затем он меняется на полностью объектно-ориентированный - для объекта App существует единый объект, и через объект App вызываются различные функции.

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

Значит, из-за изменения всего кода на объектно-ориентированное использование памяти на сервере уменьшится?

Answer 1

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

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

Answer 2

К сожалению, я тоже сделал свои тесты. Я проверил скорость, и она примерно такая же, но при тестировании использования памяти, получая memory_get_usage () в PHP, я увидел значительно большее число на стороне ООП.

116 576 байт для ООП и 18 856 байт для процедурного. Я знаю "Аппаратные средства дешево", но давай! 1000% увеличение использования? Извините, это не оптимально. И так как много пользователей одновременно попадают на ваш сайт, я уверен, что ваша память просто сгорела или закончилась. Я не прав?

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

Больше разработчиков (неаккуратных разработчиков) и более крупный сайт

Con: больше памяти используется для вашего приложения.

Pro: проще поддерживать код среди множества по всему приложению.

Один разработчик с простым сайтом

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

Pro: низкий объем оперативной памяти, немного более высокая скорость. Если ваш код написан правильно (и только хорошие разработчики могут сделать это - ха-ха), ваш код будет так же легко поддерживать.

В войнах с ОЗУ процедурные победы. В войнах за ремонтопригодность хороший код выигрывает. ;)

Поклонники ООП говорят, что ООП чище. Я видел какой-то действительно грязный ООП-код, а затем я увидел действительно ДЕЙСТВИТЕЛЬНО ЧИСТЫЙ процедурный код, написанный разработчиками, которые могли бы написать отличный код на любом языке или в любом стиле. Кодекс, с которым приятно работать. Суть в том, что если у вас неаккуратные разработчики, не имеет значения, какой стиль вы используете, у вас будет небрежный код.

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

Ура!

Answer 3

Ваш вопрос звучит для меня так: У нас есть не поддерживаемая кодовая база, перезаписать ее на Java будет быстрее?

Во-первых, вам нужно определить проблему: ваш код нечитабелен и / или сложен в обслуживании или слишком велик объем времени выполнения вашей программы? Это две полностью разных проблем.

Если у вас есть кодовая база, которую сложно поддерживать (звучит так, как вы), вы не решите эту проблему, переписав код с использованием другой парадигмы. Почему код не читается? Если разработчики пишут нечитаемый код, то переписывание его на Java или C # просто даст вам объектно-ориентированный нечитаемый код. В этом случае вам нужно улучшить навыки ваших разработчиков (нанять лучших, переучить существующих и т. Д.).

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

Answer 4

В дополнение к другим комментариям я хотел бы сказать, что OO помогает уменьшить избыточность ... что может сделать ваш код более эффективным и уменьшить объем памяти. Конечно, ОО имеет больше накладных расходов, но должно работать более эффективно в более крупных проектах.

Answer 5

Использование памяти не является преимуществом ОО. Преимущество ОО состоит в том, что код станет более понятным. Если у вас нет проблем с производительностью, вам не нужно искать способы повысить эффективность.

Answer 6

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

На самом деле это звучит почти как напротив"полностью объектно-ориентированного". Это указывает на уровень понимания того, что означает «объектно-ориентированный», что, скорее всего, НЕ приведет к уменьшению использования памяти.

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

Answer 7

Ответ и да, и нет.

Переходя на более объектно-ориентированную архитектуру, вы могли бы уменьшить объем памяти, но тогда и только тогда, когда код более эффективен.

Прямой PHP без каких-либо вызовов функций или объектов довольно быстр. Как только вы начинаете выполнять вызовы функций или объектные вызовы, все становится намного медленнее.

С Python против Ruby Vs. Python Benchmark стратегия ОО для выполнения инкрементного цикла заняла 3,7079 секунды, ориентированная на функцию - 4,3501 секунды, а использование ни одного - 0,6164 секунды. Делать простое приложение "Hello World" с OO vs. Procedural Vs. Ни один из них не набрал 4,1248 секунды против 3,7656 против 0,9309 секунды.

Таким образом, в зависимости от того, что делает ваш код и как он это делает, объекты могут быть как быстрее, так и медленнее, больше памяти или меньше памяти, или ни того, ни другого.