Основной метод 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 различных задач. У вас есть хорошая организация для этого?