Я бы не загрязнил класс 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();
    }
  }
}

Это просто чище.

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

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

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

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

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

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

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

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

Ваш основной код должен содержать как можно меньше кода.

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

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

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

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