C# Статический или нестатический класс

Question

У меня есть приложение для воспроизведения форм в форматах C#. У меня есть аудио-файлы в моей папке ресурсов и отдельный «MyAudio» статический класс, который обрабатывает все связанные с аудио работы на как играть и увеличения объема и т.д. С моей формы, я просто вызвать метод воспроизведения с помощью:

MyAudio.Play(track); 

в MyAudio классе, у меня есть объект WindowsMediaPlayer объявлен как:

private static WindowsMediaPlayer obj=new WindowsMediaPlayer(); 

Мой вопрос, с точки зрения эффективности и меньше использования памяти, это лучше объявить MyAudio класс как статический или, не статики? Целесообразно ли создать объект класса MyAudio в форме, а затем вызвать методы или напрямую вызвать с помощью класса Name? Также хорошо ли объявлять переменные экземпляра как статические?

Answer 1

Ваш вопрос действительно широк, но есть несколько принципов дизайна, которые вы можете позаботиться о, в то время как вы разрабатываете класс:

• Нужен ли мне объект и его состояние в течение всего срока применения
• нужно ли мне поддерживать состояние переменного класса для использования в будущем
• мне нужно Многопоточный или распараллелить приложение в любой момент времени
• мне нужно разъединить компонент в будущем и использовать в других Do Do сценарии, такие как Ajax based w сценарий eb

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

Предположим, что в будущем вам нужно будет распараллелить свой код для повышения производительности, тогда статика будет преследовать вас, так как это будет разделяться между потоками и всегда будет нуждаться в конструкции синхронизации, такой как lock, mutex, которая будет сериализовать все потоки, и поэтому цель будет потеряна. То же самое происходит в сценарии Web/Ajax, и ваш статический компонент не может обрабатывать несколько параллельных запросов и будет поврежден до и до синхронизации. Здесь переменная экземпляра для потока является благом, так как они выполняют распараллеливание задач/данных, не требуя блокировки, mutex

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

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

Если мы просто возьмем пример, предоставленный вами, так как это форма окна, которая выполняет операции типа Play, тогда статические будут в порядке, так как они исполняются в системе, но для тестирования представьте себе сценарий, в котором вы инициируете несколько экземпляров двойным щелчком мыши и воспроизведением на каждом из них, нажимая различные операции, тогда все они получат доступ к одному и тому же статическому объекту, и вы можете получить проблему с коррупцией, на самом деле для разрешения такого сценария вы можете даже выбрать, чтобы ваш класс был singleton, где на данный момент в памяти может существовать не более одного экземпляра, как это бывает для посланника Yahoo, независимо от того, сколько раз вы clic k, всегда появляется тот же самый экземпляр.

Answer 2

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