Если все методы являются статическими, если их класс не имеет никаких членских переменных

Должен быть символ новой строки после заголовка:

file.write("ID;NAME;PHONE;EMAIL;STREET;CITY\n")

Я не вижу причин, почему Excel не открывал этот файл. Вы получаете сообщение об ошибке?

Что касается второго примера, вы можете указать Excel использовать определенный разделитель, добавив в начало файла следующее:

sep=,
id,name,email, ..
31
задан Raedwald 22 July 2014 в 12:00
поделиться

20 ответов

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

36
ответ дан sharptooth 27 November 2019 в 21:26
поделиться

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

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

0
ответ дан James Van Huis 27 November 2019 в 21:26
поделиться

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

0
ответ дан jassuncao 27 November 2019 в 21:26
поделиться

Я недавно столкнулся с той же проблемой. Я использовал статический метод. Этот метод в основном возвращает путь к папке, я должен сохранить все определяемые пользователем настройки. Теперь проблема состоит в том, что я должен записать тестовый сценарий, который в основном вытирает все от папки. Я определенно не хотел бы удалять фактические файлы, и поэтому я захочу, чтобы тот метод возвратил что-то еще. Yakes.... Я не могу casue, я не могу дразнить метод, поскольку это статично. Оставленный без удачи, но измениться это на не статический метод и иметь класс реализует интерфейс с тем методом. Тогда я могу легко дразнить тот интерфейс и иметь возврат метода любой путь, который я хочу.

End result. Making it a not static gives you more functionality. Make class Singleton and you have everything a static does for you plus loosely coupling.
1
ответ дан Sheraz 27 November 2019 в 21:26
поделиться

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

В нашей компании мы используем поблочное тестирование и тестирование системы с Junit. (org.junit) Там это не проблема вообще для тестирования статических методов с этим пакетом тестов.

, Таким образом, я сказал бы: да делают их статичными.

(С комментарием, что я не знаю процедуру тестирования, где тестирование статических методов является проблемой)

1
ответ дан michel.iamit 27 November 2019 в 21:26
поделиться

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

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

Снова, этого не могло бы произойти с Вашим определенным кодом, но я был однажды в этом приложении с тоннами классов как это (40 - 60 или больше)

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

было бы легче, если я мог бы иметь, вводят новые реализации для тех определенных частей.

строки кода этого приложения в 500k и не все они были в Java, которые делают рефакторинг тяжелее.

при использовании этого в 1k проекте строки, тогда он не имеет значения вообще.

1
ответ дан OscarRyz 27 November 2019 в 21:26
поделиться

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

1
ответ дан taglius 27 November 2019 в 21:26
поделиться

Это зависит, какова Ваша цель:

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

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

1
ответ дан Daniel 27 November 2019 в 21:26
поделиться

Я полагаю, что методы не сохраняющие состояние должны обычно быть статическими.

  • ясно в коде, что никакой объект не включен
  • , Это избегает бессмысленного вызова конструктора

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

2
ответ дан Steve B. 27 November 2019 в 21:26
поделиться

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

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

2
ответ дан Raibaz 27 November 2019 в 21:26
поделиться

При создании этого статичным Вы не можете ввести другую реализацию легко.

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

OTOH, осуществляя рефакторинг инструменты может заменить все вызовы к статическому методу довольно легко, таким образом, это не очень важно так или иначе.

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

2
ответ дан Pete Kirkham 27 November 2019 в 21:26
поделиться

Ответ - да и нет. Все это зависит от цели поведения метода. Например:

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

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

3
ответ дан Antonio 27 November 2019 в 21:26
поделиться

Я ясно сказал бы никакой .

намного более трудно измениться в будущем при вызове статических методов вместо экземпляра. С методами экземпляра легко ввести Ваш сервис, например, в Java с контейнером МОК/DI как Guice или Spring.

3
ответ дан Stephan Schmidt 27 November 2019 в 21:26
поделиться

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

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

4
ответ дан Magnus 27 November 2019 в 21:26
поделиться

Я сделал бы все это статичным.

4
ответ дан Otávio Décio 27 November 2019 в 21:26
поделиться

Это - непростое решение. Помните то, что Josh Bloch говорит о API :

API, как ромбы, навсегда. У Вас есть один шанс разобраться в нем, так дайте ему свое лучшее.

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

7
ответ дан Julien Chastang 27 November 2019 в 21:26
поделиться

Я был бы избегать создание их статичных. Пока в данный момент, который может иметь смысл, Вы, май в будущем хочет добавить некоторое поведение. например, в данный момент у Вас был бы механизм вычисления по умолчанию (стратегия):

CalcService cs = new CalcService();
cs.calcPrice(trade, date);

и позже можно хотеть добавить новый механизм вычисления:

CalcService cs = new CalcService(new WackyCalculationStrategy());
cs.calcPrice(trade, date);

при создании этого класса instantiatable, тогда можно создать различные экземпляры и раздать их, инстанцировать на лету и т.д. Можно ли дать им продолжительное поведение (например, сколько вычислений, включающих торговлю X, этот объект сделал? и т.д.)

7
ответ дан Brian Agnew 27 November 2019 в 21:26
поделиться

Существует общее настроение против статических классов в эти дни по причинам тестируемости.

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

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

19
ответ дан Jack Ryan 27 November 2019 в 21:26
поделиться

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

23
ответ дан Eric Petroelje 27 November 2019 в 21:26
поделиться

Запах статики

В большинстве случаев статический метод является примером поведения, разведенного от данных. Это указывает, что что-то не инкапсулируется. например, если Вы видите, проверяют методы для номера телефона, электронное письмо и т.д. в util классах, спрашивают, почему они не эти поля, не имеют их собственных классов. Даже классы библиотеки могут быть расширены для размещения пользовательского поведения. Наконец в особых случаях как java.lang. Строка (который является окончательным) Вы могли использовать пользовательский myproject. Строка (с дополнительным поведением), который делегирует к java.lang. Строка

Объекты являются способом получить доступ к поведению на языках OO. Не полезно волноваться о стоимости объектных помех инстанцирования и использования вместо этого. Для большей части программного обеспечения для бизнеса это - 'пенс мудрый фунт глупый' подход к производительности.

Иногда, Вы используете функторы (методы, которые не используют объектное состояние) для выражения намерения. Не означает, что они должны быть сделаны статичными. Предупреждения IDE, которые предлагают "метод, могут быть сделаны статичными", не должен быть отнесен серьезно.

0
ответ дан ottodidakt 27 November 2019 в 21:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: