Статические методы хороши для масштабируемости?

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

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

На самом деле я думаю, что ASP Classic доказал это.

Хороши ли статические методы и классы для масштабируемости?

Одно мало связано с другим.

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

Неправильный. Почему ты так думаешь?

Так является ли хорошей практикой программирования писать статические методы везде, где это возможно?

Нет. На самом деле это очень плохая практика, потому что она отказывается от преимуществ объектно-ориентированного программирования, связанных с ремонтопригодностью.

Есть три проблемы, которые следует учитывать при использовании статических методов:

1. Вы можете создать узкое место, если ваш статический метод имеет большую критическую область. Самым большим, конечно, является объявление всего метода синхронизированным. Если он может выполняться только по одному, то это потенциальная проблема;
2. Является ли то, что он делает, по-прежнему согласованным, если вы используете один и тот же метод на разных виртуальных машинах и на разных машинах? и
3. Любой метод, основанный на статических методах, имеет проблемы с модульным тестированием.

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

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

1 Масштабирование по количеству запросов, обрабатываемых в секунду

Этот тип масштабирования обычно заключается в добавлении большего количества компьютеров в кластер для повышения общей пропускной способности системы. Повышение масштабирования часто заключается в первоначальном уменьшении количества общих ресурсов, используемых за счет использования кешей, а затем в разделении доступа к данным на сегменты.

2 Масштабирование данных

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

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

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

Редактирование для добавления:

Если вам интересно, как метод экземпляра может быть фактически разделен между экземплярами: это потому, что каждый вызов метода экземпляра неявно передает ссылку на объект экземпляра в метод. Обычно это называется «неявным this». Другими словами, когда вы определяете или вызываете метод экземпляра с двумя параметрами, такими как myMethod(a, b), вы можете думать о нем как о myMethod(this, a, b) , и Java позаботится об этом параметре за вас, и вам не придется явно определять или передавать его.

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

Для объяснения того, что происходит на уровне байт-кода Java, вот ссылка: http://www.artima.com/underthehood/invocationP.html (см. материал вокруг: «Objectref — это неявный указатель this, который передается любому методу экземпляра».)

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

Наконец, если вы считаете, что статические методы — это то, что нужно, вам не следует использовать объектно-ориентированный язык, такой как Java. Попробуйте C или Pascal или классические Basic-диалекты.

Я думаю, вы лаете не на то дерево:

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

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

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