2016-09-14 2 views
3

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

Например printPlusOne ниже будет называться пять раз:

class Count{ 

     public static void main(String[] args) { 
      for(int i = 0; i < 5; i++){ 
       printPlusOne(i); 
      } 
     } 

     public static void printPlusOne(int i){ 
      int sum = i + 1; 
      System.out.println(sum); 
     } 
    } 

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

 class Count{ 

     public static void main(String[] args) { 

      //The below will print only once at the beginning of the program. 
      //Should I create a method for it even if it runs only once? 

      System.out.println("This is the introduction."); 
      System.out.println("The program will return a count"); 
      System.out.println("Have fun.") 
     } 
    } 
+12

Число раз, когда код вызывается, не имеет значения.Вы должны создать метод, если у вас есть набор из одной или нескольких операций, которые могут быть инкапсулированы в одно интуитивное и описательное имя для этих общих операций. То есть, если у вас есть одна или несколько строк кода, чтобы «сделать что-то», тогда вы поместите их в метод, который указан для этой вещи. – David

+0

Заметка о вашем первом примере: я бы поставил весь цикл в методе, подобном: 'printNums (int start, int end);' он был бы более гибким таким образом. Я также позабочусь о том, чтобы решить привязать метод к определенному потоку вывода, поскольку он делает код менее гибким. – ChiefTwoPencils

+0

@ChiefTwoPencils Спасибо. Я просто использовал это как быстрый пример. – pseudorandom

ответ

1

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

2

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

3

Здесь вы найдете не только «эмпирические правила». Целый «clean code movement» (каким-то образом основанный на превосходном абсолютном обязательном чтении «Чистого кода» Роберта Мартина, идите получить бесплатный PDF сейчас), и его принципы говорят нам: «чем больше методов, тем лучше».

Или точнее:

  1. Существует «Single ответственности» принцип - это говорит, что любая «штуковина» в программировании (модуль, класс, метод) должна иметь «единую ответственность» только. Итак, метод «одно» и только одно.
  2. Принцип «Один слой абстракции»; в основном сообщив вам, что у вас есть не более один если, или один цикл, или один try-catch в ваших методах.

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

И наконец: один важный аспект «многих коротких методов лучше, чем несколько длинных»: такая настройка помогает «вашему мозгу» быстрее схватить контент. Дело в том, что ваш мозг всегда пытается найти контекст, «границы» при изучении всего, что записано. И это довольно просто: если вы пишете код, который имеет явные, легко захватываемые границы; то вы помогаете своему мозгу, когда вы вернетесь позже и изучите код. Но если вы слишком много вещей в один метод, ваш мозг начнет «срезать» содержание метода на более мелкие части. Другими словами: вы теряете мозговые циклы процессора, заставляя свой мозг «игнорировать» тот факт, что в этом одном большом методе скрыто много мелких методов.

И для записи: не беспокойтесь о эффективности работы. JVM/JIT действительно хорош в оптимизации небольших методов; чем меньше, тем легче может быть inline их во время выполнения.

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