2016-09-26 2 views
1

Я не очень хорошо знаком с java. Я создал веб-сервер трикотажа. Существуют различные функции, такие как startRodio(), stopRadio(), setRadioIp() ... Я создал один класс RequestHandler для обработки запросов http и еще одного Radio класса, который их реализует. Все свойства и методы класса Radio являются статическими. это выглядит какПри использовании статических классов в java

Radio

class Radio{ 

public static boolean radionOn; 
public static String radioIpadress; 


public static boolean startRadio(){ 
radioOn = true; 
// some other operation 
} 
... 

RequestHandler

classe RequestHandler { 

@path(/startRodio) 
..... 
if (!Rodio.radioOn) 
Radio.startRadio(); 

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

+0

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

ответ

0

Проще говоря: не использовать статические.

статический является анонимностью в хорошем дизайне OO. Это приводит к прямой связи между вашими классами. Это затрудняет последующую замену «реализации»; и это затрудняет запись разумных модульных тестов.

Значение: по умолчанию вы не используете статические. Могут быть ситуации, когда это нормально использовать; но пример кода, который вы показываете, совсем не похож на то, что вы должны использовать static.

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

1

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

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

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

1

Лучше избегать использования статических переменных. Это не очень хорошая практика. Статические переменные имеют глобальные масштабы, которые не дают вам тестирования так сильно. Также все может изменить статические переменные. более того, использование статического не является безопасностью потоков. Кроме того, вы не контролируете статические переменные i терминов их создания и уничтожения. Поэтому не рекомендуется использовать статику.

1
  1. Просто не используйте static переменных. Он непосредственно соединяет несколько классов .
  2. Вы можете использовать одиночные игры вместо статического, если вы уверены, что вам нужен нужен только один объект.
0

Это зависит от того, что вы ищете.

Допустим, вы создаете 4 объекта Радио. radioOne ...., radioFour ...

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

Radio.radionOn = true;

а не radioOne.radioOn = true;

Итак, я предлагаю вам сделать только те свойства static, которые будут распространены для всех объектов. Если все свойства будут подпадать под этот объект, то , то это означает, что вы хотите, чтобы только один объект для класса, потому что все ваши объекты будут вести себя одинаково. Лучше иметь один объект. В этом случае перейдите к шаблону singleton для создания объекта.

Смежные вопросы