Основной метод Java, хороший стиль кодирования

У меня было довольно длинное обсуждение с моим другом о правильном и хорошем использовании основного метода в Java. В принципе у нас есть класс вроде этого:

public class AnImporter implements Runnable {
  // some methods, attributes, etc.
}

Но куда поставить основной метод? Я считаю хорошей практикой "держать код там, где он принадлежит", тем самым превратив вышеуказанный код в

public class AnImporter implements Runnable {
  public static void main(String [] args){
    // Startup code for Importer App here
  }
  // some methods, attributes, etc.
}

Пока мой приятель утверждает, что "код запуска не имеет ничего общего с самим приложением", поэтому его следует поместить в другой класс, например:

public class AnImporter implements Runnable {
  // some methods, attributes, etc.
}

public class AnApplication {
  // Nothing here
  public static void main(String [] args){
    AnImporter a = new AnImporter();
    // Startup code here
  }
  // Nothing here
}

Несмотря на то, что мы обсуждали этот вопрос в течение некоторого времени, мы оба не пришли к выводу, каким образом это лучший подход в Java. Какое у вас отношение к этой теме? Где и что самое главное, почему вы размещаете свой основной метод, когда вы его разместили?

Ответ 1

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

Ответ 2

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

Но я бы сказал, что читаемость и тестируемость - две хорошие причины для выхода из основного метода (и его класса) ASAP. Но эй... это только я;)

Ответ 3

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

public class App {
  public static void main(String args[]) {
    Thread t = new Thread(new Blah());
    t.start();
      synchronized (t) {
        t.wait();
      }
  }
}

public class Blah implements Runnable {
  public void run() {
    // do normal stuff
  }
}

вместо:

public class Blah implements Runnable {
  public void run() {
    // do normal stuff
  }

  public static void main(String args[]) {
    Thread t = new Thread(new Blah());
    t.start();
    synchronized (t) {
      t.wait();
    }
  }
}

Он просто чувствует себя чище.

Ответ 4

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

1) Главное - это, в некотором смысле, взломать, чтобы ваша программа запускалась из командной строки. Любой класс, содержащий его, должен иметь одну ответственность: пусть программа запускается из командной строки. Помещая это с вашей основной runnable, вы загрязняете runnable.

2) Возможно, у вас будет несколько сетей (например, с определенными параметрами по умолчанию, со специальными режимами и т.д.).

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

4) Иногда проще оставить основной в пакете по умолчанию, чтобы ускорить выполнение во время выполнения (например, java myblabla par1 par2 par3), но вы определенно не хотите, чтобы остальная часть вашего кода была в пакете по умолчанию.

Ответ 5

Интерфейс к основному (список строк) примерно бесполезен, за исключением оболочки ОС.

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

Действительно, ваш public class ThisIsMyApp {...} должен быть не чем иным, как интерфейсом ОС для реальной работы, которая находится в другом месте.

Ответ 6

Я бы отделил основной метод от кода.

Хотя у меня также есть другой тип проекта. Он включает в себя не настоящую рабочую программу для решения. Здесь мне нужно запускать различные решения для разных задач, используя (и разрабатывая) одну и ту же библиотеку. Различные проблемы не параллельны. Мне нужно запустить только одну проблему из моей среды разработки. Мне было удобно использовать один и тот же проект с огромным количеством классов с помощью методов PSVM.

Этот проект содержит решения для конкурсов программ для более чем 400 различных задач. У вас есть хорошая организация для этого?