Основной метод Java, хороший стиль кодирования
23463 просмотра
6 ответа
Я довольно долго беседовал с моим другом о правильном и правильном использовании основного метода в 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. Какое у вас мнение по этой теме? Где и, самое главное, почему, вы размещаете свой основной метод там, где вы его разместили?
Автор: kryoko Источник Размещён: 12.11.2019 09:30Ответы (6)
35 плюса
Я согласен с твоим другом. В AnImporter вы создаете потенциально многократно используемый сервис, который потенциально может использоваться в нескольких программах с несколькими основными. Таким образом, создание одного основного специального и встраивание его в AnImporter не имеет особого смысла.
Автор: Clint Miller Размещён: 08.04.2009 10:3814 плюса
Я бы, наверное, пошел с твоим другом, так как предпочел бы как можно быстрее выйти из класса основным методом. Это помогает упростить тестирование, когда вы хотите протестировать атомарно (только запускаемый класс) или хотите что-то сделать. Чем раньше вы выйдете из основного метода, тем больше у вас вариантов. Если у вас есть один класс с основным методом и другими вещами, он может быстро запутаться. (даже если это может показаться не таким простым примером, например, описанным вами)
Но я бы сказал, что удобочитаемость и тестируемость являются двумя вескими причинами выхода из основного метода (и его охватывающего класса) как можно скорее. Но эй .. это только я;)
Автор: digiarnie Размещён: 08.04.2009 10:3911 плюса
Я бы не загрязнил класс 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();
}
}
}
Это просто чище.
Автор: cletus Размещён: 08.04.2009 10:397 плюса
Я всегда отделяю основное от остального кода по нескольким причинам:
1) Главное - это, в некотором смысле, хакерство, позволяющее запускать вашу программу из командной строки. Любой класс, содержащий его, должен нести одну ответственность: пусть программа запускается из командной строки. Поместив его в ваш основной работоспособный объект, вы загрязняете его.
2) У вас может быть несколько сетей (например, с определенными параметрами по умолчанию, специальными режимами и т. Д.)
3) Вы можете запустить программу из другой среды (например, плагин Eclipse или модуль OGSI, апплет, веб-инструмент и т. Д.). В этих случаях вы хотели бы ограничить доступ к своей основной. Помещение этого с функциональностью предотвращает это.
4) Иногда проще оставить свой main в пакете по умолчанию, чтобы ускорить выполнение во время выполнения (например, java myblabla par1 par2 par3), но вам определенно не нужен остальной код в пакете по умолчанию.
Автор: Uri Размещён: 08.04.2009 10:432 плюса
Интерфейс main (список строк) практически бесполезен, за исключением оболочки ОС.
Ваш основной код должен содержать как можно меньше кода.
Действительно, вы public class ThisIsMyApp {...}
должны быть не чем иным, как интерфейсом ОС для реальной работы, которая есть в другом месте.
0 плюса
Я бы отделил основной метод от кода.
Хотя у меня тоже есть другой тип проекта. Он включает в себя не настоящую рабочую программу для решения. Здесь мне нужно запустить разные решения для разных задач, используя (и разрабатывая) одну и ту же библиотеку. Разные проблемы не параллельны. Мне нужно запустить одну единственную проблему из моей IDE. Мне было удобно использовать один и тот же проект с огромным количеством классов с методами PSVM.
Этот проект содержит программные конкурсы для решения более 400 различных задач. У вас есть лучшая организация для этого?
Автор: kisp Размещён: 23.11.2011 01:15Вопросы из категории :
- java В чем разница между int и Integer в Java и C #?
- java Как я могу определить IP моего маршрутизатора / шлюза в Java?
- java Каков наилучший способ проверки XML-файла по сравнению с XSD-файлом?
- java Как округлить результат целочисленного деления?
- java Преобразование списка <Integer> в список <String>
- java Почему я не могу объявить статические методы в интерфейсе?
- java Библиотека Java SWIFT
- java Выключение компьютера
- java Как я могу воспроизвести звук на Java?
- java Когда выбирать отмеченные и непроверенные исключения
- coding-style Когда вы используете ключевое слово "это"?
- coding-style Синтаксические стили C ++
- coding-style Должна ли функция иметь только один оператор возврата?
- coding-style Сколько аргументов конструктора слишком много?
- coding-style Одинарные кавычки против двойных кавычек в Python
- coding-style Вы должны использовать международные идентификаторы в Java / C #?
- coding-style Бесплатный инструмент для проверки исходного кода C / C ++ на соответствие стандартам кодирования?
- coding-style Вкладки и пробелы в программировании на Python
- coding-style Должны ли операции импорта всегда находиться в верхней части модуля?
- coding-style Order of items in classes: Fields, Properties, Constructors, Methods