Il metodo principale dovrebbe essere separato in una classe separata? [chiuso]

Question

Il metodo principale dovrebbe essere separato in una classe separata? [chiuso]

#1 da (4 voti)
#2 da (1 voti)

3

In Java metodi principali spesso fare poco più che analizzare gli argomenti della riga di comando e inizializzare un oggetto che poi prende il sopravvento, per esempio:

public class FooServer {
    // ...

    public static void main(String[] args) {
        // Process arguments ...
        FooServer server = new FooServer(...);
        // Initialize server ...
        server.start();
    }
}

Ho visto che alcuni software estrapolano questo metodo principale in una classe "principale" separata (spesso finendo in Launcher o Main ):

public class FooServer {
    // ...
}

public class FooServerLauncher {
    public static void main(String[] args) {
            // Process arguments ...
            FooServer server = new FooServer(...);
            // Initialize server ...
            server.start();
        }
}

La classe "main" è strettamente collegata all'altra classe, quindi suppongo che la classe "main" sia separata in modo da non inquinare l'interfaccia dell'altra classe.

Ho discusso la questione con un collega e la persona era dell'opinione che i programmatori contemporanei orientati agli oggetti riducessero le classi in troppe piccole classi separate per fingere che tutto sia intercambiabile mentre non lo è. La persona ha sostenuto che questo è un buon esempio del problema in quanto l'unico scopo del metodo principale è quello di avviare un oggetto dalla riga di comando e quindi è di fatto parte della sua interfaccia.

Esistono altri argomenti oggettivi contro la separazione del metodo principale nella sua classe?

java interfaces command-line

posta user3998276 04.11.2015 - 15:02

fonte

2 risposte

Leggi altre domande sui tag java interfaces command-line

Dovrei aggiungere un livello per mantenere l'oggetto sempre valido e immutabile? È una buona idea includere librerie aggiuntive nei barattoli?

score 4 · Answer 1

Il pattern che hai citato non è necessariamente il pattern usato in tutti i programmi. Ad esempio, se voglio creare un programma che legge i messaggi, li elabora e invia l'output da qualche parte, potrei avere una struttura main che è più simile a questa:

public static void main(String[] args)
{
    Reader reader = new Reader(args[0]);
    Writer writer = new Writer(args[1]);
    Processor processor = new Processor(args[2]);
    reader.start();
    writer.start();
    processor.start();
    ...
}

L'essenziale è che la cosa che sta lanciando parti della mia applicazione non sta solamente usando una classe, come nei tuoi esempi. Qui inserirò probabilmente la funzione main in una classe MyProgramLauncher , perché non è direttamente legata a una singola classe e potremmo potenzialmente aggiungere altre classi in futuro (inizializzazione della registrazione, connessione al database, motore grafico, ecc.)

main è anche un luogo logico per verificare tutte le condizioni preliminari per l'esecuzione del programma. Per esempio. Se non riesci a connetterti al tuo database, potresti voler fallire presto e chiedere all'utente di verificare le impostazioni della connessione a Internet e riprovare.

Se ho un metodo principale come FooServerLauncher , allora lo inserirò in FooServer . Fintanto che esiste un metodo main e non fa riferimento a nient'altro che FooServer , quindi appartiene al file FooServer . In alternativa, se hai più file principali che utilizzano FooServer , devono essere nelle loro classi di stile Launcher , in modo che la funzionalità di ciascun 'eseguibile' del tuo sistema rimanga separata.

Analizzandolo con le tipiche metriche progettuali (se confrontato con main in FooServer ):

Leggibilità - Se qualcosa è ridotto, perché la cosa che esegue l'esecuzione e la cosa che viene eseguita sono separate. E in senso molto letterale devi leggere due file diversi per capire cosa sta succedendo.
Modularità - Aumentata, ma direi che sta seguendo il dogma di "modularità" in un errore.
Mantenibilità - Si riduce anche per ragioni analoghe alla leggibilità. Mantenendo FooServer probabilmente dovrai modificare FooServerLauncher . Direi che è molto meno probabile che altera FooServer e dimentichi di aggiornare main come necessario se sono nello stesso file. Avere i file separati introduce "lontano dagli occhi, lontano dalla mente".
Accoppiamento - Alto, perché dipende al 100% dall'implementazione di FooServer . Nel tuo esempio, main ha passaggi di inizializzazione e avvia FooServer , che a seconda delle tue preferenze potrebbe essere troppo accoppiato.
Coesione - direi bassa, per la stessa ragione per cui abbiamo un accoppiamento elevato. Se tutto in main esiste per fare qualcosa legato a FooServer , allora il posto logico dove mettere main è in FooServer .

Per un paio di questi penso che potresti obiettare che rimangono gli stessi, ma non mi viene in mente il modo in cui sono migliorati. Quindi, tutto sommato, avere main in un file separato sembra essere uguale o minore di averlo nello stesso file.

score 1 · Answer 2

In Java, quasi tutto è un oggetto, quindi deve essere dichiarato chiaramente main (). La sua preoccupazione è distinta dal resto della nostra classe (che definisce alcuni dati e comportamenti che stiamo cercando di incapsulare), che sta facendo in modo che il programma sia pronto per eseguire l'intera operazione.

Secondo me, main non dovrebbe essere spinto con gli altri dati e il comportamento di una classe. La preoccupazione principale del metodo è l'esecuzione del nostro programma. Tornerà alla logica necessaria che viene dichiarata all'interno del suo corpo. Detto questo, vorrei andare avanti e tenerlo lontano da qualsiasi altra classe e / o logica del tuo programma.