Как параметры и их использование в методах влияют на решение о разработке статического / экземпляра?

Question

Просто простой вопрос:

Я прочитал, что класс должен быть статическим, если он не изменяет свой экземпляр. Поэтому, если у меня есть класс, который называется Account и у него есть свойства, такие как Id, Duration и т. Д., И они не модифицируются классом, то это можно сделать статическим, в противном случае он должен оставаться статическим.

Как это влияет (мутирует ли сам экземпляр через его свойства) на решение статического / экземпляра?

Кроме того, если класс принимает множество параметров (скажем, этот класс Account, придерживаясь нашей аналогии), но не изменяет экземпляр (так что переменная Account не изменяется - ничего подобного Account.x = y //, откуда y другой класс), я полагаю, это можно сделать статическим? Значит, это не параметры или проблема, а то, что они делают?

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

Я заметил, что в статических методах более 100 потоков (это относится к статическому методу, так как он имеет дело с параметрами) на C #, и я прочитаю все это, поскольку есть хорошие вопросы и хорошие ответы.

Спасибо

Answer 1

Похоже, вы хотите сделать класс неизменным, а не статичным?

Вот определение статического класса из C # 3 в двух словах: «Класс может быть помечен как статический, что означает, что он должен состоять только из статических членов и не может быть разделен на подклассы. Классы System.Console и System.Math являются хорошими примерами статических классов».

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

Answer 2

Похоже, вы спрашиваете о методах и классах, поэтому у вас есть 2 вопроса.

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

Неизменные классы, как указала Эбби Фихтнер, часто бывают полезными.

Статические классы часто не хорошие вещи. Помимо проблем с многопоточностью, на которые указал DancesWithBamboo, вы имеете дело с глобальными данными, если класс не является неизменным. Вы когда-нибудь пытались отлаживать программу, которая имеет много глобальных переменных?

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

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

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

Answer 6

Я не уверен, что полностью понимаю, что вы пытаетесь сделать, но вот некоторые мысли:

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

2) Статический класс не может иметь переменных экземпляра, он может содержать только статические переменные, поэтому в вашем примере все свойства, такие как ID, Duration, должны быть статическими (не рекомендуется для учетной записи)

3) Расходы: если вам нужно совместно использовать дорогостоящие ресурсы, создание статической переменной позволяет реализовать шаблон Singleton, так как статический разделен между всеми экземплярами этого типа, обычно это только для чтения и создание экземпляра один раз. Примерно так:

public class Singleton
{
    private static Singleton _instance = new Singleton();

    private Singleton() {}

    public static Singleton Instance {
        get {
                return _instance;
        }
    }
}

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

Надеюсь, это послужит руководством

Answer 7

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

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

Если у вас есть класс Account, который имеет свойства, которые никогда не меняются, то, что вы просматриваете, является единичным экземпляром неизменяемого класса. Вы можете разработать это, используя ключевое слово static, чтобы обеспечить создание только одного экземпляра класса Account, или, в качестве альтернативы, объявить Properties как константу.

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

Я особенно презираю static, потому что это большая проблема, если у вас многопоточное приложение.