Solo le funzioni statiche possono essere stampate sullo schermo?

Penso che non ci sia un principio ampiamente noto che affermi che solo i metodi statici dovrebbero stampare sullo schermo.

Ad esempio, un'app CLI può avere logger iniettati all'interno dei suoi oggetti. Tali logger verrebbero stampati su un file per impostazione predefinita, ma impostando un parametro è possibile attivare una "modalità di debug" e iniettare uno screen logger. In tal caso i logger, che non sono statici, verrebbero stampati sullo schermo.

C'è un principio che suggerisce che solo il livello di presentazione debba essere stampato sullo schermo (MVC), ma potrebbero esserci delle eccezioni, come nell'esempio che ho dato sopra. Il livello di presentazione non è necessariamente composto solo da metodi statici. Quindi non si tratta di stabilire se i metodi che stampano sullo schermo siano statici, ma se i metodi che stampano sullo schermo appartengono (concettualmente) al livello di presentazione.

NOTA: MVC è stato inizialmente introdotto per applicazioni desktop / CLI per risolvere esattamente questo tipo di problema. Il concetto è stato applicato in seguito anche alle app Web.

Although originally developed for desktop computing, model–view–controller has been widely adopted as an architecture for World Wide Web applications in major programming languages. Wikipedia - MVC

La risposta breve è "No". Non esiste un principio generale di progettazione Java che suggerisca che solo le funzioni statiche debbano essere stampate sullo schermo.

Questo tipo di decisioni devono essere prese a livello di progetto. Ad esempio, se tu come ingegnere / progettista di software potresti trovare qualche motivo per cui per il tuo progetto ha senso limitare l'output ai metodi statici. Ma non riesco a immaginare perché qualcuno dovrebbe prendere questa decisione sul design.

Nella tua domanda parli di lanciare un'eccezione da una chiamata di metodo "su" al metodo principale / metodo statico e fare la logica aziendale di "cosa facciamo ora?" Là. Questo è ragionevole e appropriato, ed è per questo che Java ci dà la possibilità di definire "lanci". Quello che hai affermato è esattamente giusto, il tuo file opener oggetto può essere definito solo per l'apertura di file, cosa fare quando ciò fallisce è responsabilità del chiamante.

Anche se è tutto vero e corretto, non esiste una regola per cui il chiamante debba essere un metodo statico. Ad esempio, potresti avere un metodo principale statico che crea un oggetto Database e quell'istanza va e prova ad aprire un file. Quando ciò non riesce (l'oggetto Database stesso) può stampare un messaggio "non riuscito ad aprire il file" sullo schermo e quindi procedere a provare a creare un database tramite una connessione socket ad un server web. Questo è ipotetico, ma è un esempio reale di un oggetto che è stato istanziato che entrambi (1) gestiscono eccezioni generate, AND (2) stampa l'output sullo schermo nei metodi non-static . Questo è perfettamente accettabile e l'uso molto standard di Java.

Come designer e lead del progetto, potresti dire ai tuoi programmatori, "Non gestire le eccezioni e non stampare sullo schermo. Esplicitamente genera eccezioni da tutte le chiamate di metodo per tutto e le gestiremo in main e stampa solo da lì. " Potresti farlo, ma dovresti essere licenziato se lo fai. Detto questo, esistono implementazioni di registrazione davvero efficaci e persino java ha una propria registrazione in modo da avere un buon livello di controllo su ciò che viene stampato sullo schermo / per registrare i file, ecc. È meglio usare semplicemente le istruzioni di registrazione in un modo controllato e prevedibile e metterle ovunque siano necessarie , che si tratti di metodi statici o non statici.

'Ruolo' è ciò che determina il comportamento prescritto dei metodi

L'essenza della spiegazione di seguito è "No".

Essendo a conoscenza della tua conoscenza delle restrizioni linguistiche (è consentito o meno), presumo che questa sia più una domanda sui principi che guidano un progetto, cercherò di spiegare in questi termini.

La base su cui deve essere deciso, se un metodo o anche tutti i metodi di una determinata classe dovrebbero o non dovrebbero essere stampati sullo schermo, è Ruolo .

Cercando di seguire il principio di Responsabilità Singola per quanto possibile, una classe dovrebbe generalmente essere quella che interagisce con gli utenti o quella che non interagisce con gli utenti. Solo le classi che risiedono sul bordo del sistema (lato UI, non bordo n / w) generalmente saranno stampate sulla console o sulla GUI come progettato, attenzione che queste classi verranno create solo dopo la decisione sull'interfaccia utente (console o GUI) è fatto.

Tutte le altre classi dovrebbero generalmente esistere per eseguire funzioni che assistono nello stadio intermedio del risultato che si sta formando. Se si trovano ad affrontare situazioni in cui alcune informazioni inaspettate devono essere condivise all'esterno, dovrebbero preferibilmente utilizzare canali come la registrazione, l'aumento delle eccezioni o la restituzione dei valori di errore. Questo può quindi essere consumato, interpretato e condiviso all'esterno dell'utente, secondo l'interfaccia decisa.

Ad esempio, se creo una libreria matematica che stampa un messaggio alla console quando affronta lo scenario diviso per zero, dovrebbe essere riscritta se in seguito voglio utilizzare lo stesso algoritmo / libreria per una GUI ambiente basato. Ciò sarebbe in violazione del concetto di modularità / riusabilità, uno dei principali pilastri dell'OOP. Si noti che il "ruolo" delle mie classi matematiche consiste nell'eseguire il calcolo e non nel presentarlo all'utente. Ci dovrebbe essere una classe diversa che gestisca il lavoro di interazione con gli utenti. Questa altra classe (o serie di classi) si occuperà di come presentarla all'utente (Console / GUI), come formattarla / visualizzarla (Testo / Tabelle / Grafici / ecc.)

Questo è un risultato diretto della considerazione di due dei principi di progettazione di classe, vale a dire, principio di responsabilità singola e principio di segregazione dell'interfaccia, al fine di evitare di indulgere in interfacce grasse.

Spero che non sembri piuttosto vago.