Senza sapere molto sulla tua struttura attuale e sui cambiamenti comportamentali che prevedi, potrei dire, forse il schema di comando potrebbe essere di aiuto.

Fondamentalmente, invece di dichiarare molti metodi diversi nella tua classe Session e di conseguenza cambiare la sua API per tutto il tempo, ti forniresti un'interfaccia Command e tutti i tuoi comandi effettivi, cioè cosa deve essere effettivamente fatto (e sarebbe altrimenti in metodi diversi), andare in implementazioni concrete di Command . In realtà, sembra un po 'come, il tuo metodo submitJob è già in fase di ricezione di comandi come quelli; aggiungi solo un parametro Command ...: -)

class Session {

    public void submitJob(JobCommand job) {
        job.execute();
    }
}

interface JobCommand {

    public void execute();
}

Codice contro un'interfaccia

Session non eredita i 2 metodi da un'interfaccia. È per amore della brievità? In caso contrario, dovresti sempre dichiarare un'API con un'interfaccia.

public interface Session {
    void connect();
    void submitJob();
} 

public class HttpSession implements Session {
    @Override
    public void connect(){

    }

    @Override
    public void submitJob() {

    }
}

Evoluzione della tua API

Il fatto che i metodi non prendano alcun parametro potrebbe bloccarti in futuro. Spiegazione:

Session session = SessionFactory.create();
session.connect();

Il codice sopra potrebbe essere un esempio dell'uso corrente dell'API dell'utente. Forse in futuro vedrai la necessità di accettare un parametro token per connect . In questo caso sei fregato perché hai bisogno di cambiare la tua interfaccia in

public interface Session {
    void connect(String token);
    void submitJob();
} 

Che cosa succede se è necessario aggiungere un altro parametro? e cambia la tua interfaccia in

public interface Session {
    void connect(String token, String username);
    void submitJob();
} 

Sembra che tu sia fregato ancora e ancora ...

Per risolvere questo problema, una pratica che ho già visto nella progettazione dell'API (disclaimer: non so se è una buona pratica o meno) è che aggiungi un parametro oggetto al metodo.

public interface Session {
    void connect(ConnectParameters params);
    void submitJob();
} 

public final class ConnectParameters {
    private final String token;
    private final String username;
    //TODO: add future parameters here

    ...
}

Con questa soluzione, hai la garanzia che la firma non evolverà e interromperà la tua API.

Seguite semplicemente i principi di progettazione SOLID dati da Uncle Bob insieme a OOP fondamentale ad es. basso accoppiamento tra modulo, alta coesione ecc.