Va bene deprecare i metodi che devono essere pubblici a causa del modello di packaging ma non devono essere utilizzati al di fuori del codebase in Java?

2

Attualmente sto lavorando a un progetto semi-large che ha diversi pacchetti. Ci sono 3 pacchetti principali, un pacchetto "client", un pacchetto "server" e un pacchetto "comune". Ci sono due vasi, uno per il client e uno per il server, ciascuno contenente il proprio pacchetto e il pacchetto comune. Come è implicito dai nomi dei pacchetti, c'è un server e un client. I client si connettono al server e scambiano messaggi. Questi messaggi assumono la forma di una sottoclasse serivizzata di Messaggio. Tutte le sottoclassi di messaggi sono nel pacchetto comune. Quando viene ricevuto un messaggio, viene chiamato un metodo sulla classe del messaggio per gestire il messaggio. C'è una sottoclasse di messaggi che è responsabile dell'invio del nome dei client ai server. Nel metodo chiamato quando il server lo riceve, chiama quindi un metodo setName () sull'oggetto che rappresenta la connessione tra il server e il client.

Per ovvi motivi, non voglio che i programmatori esterni chiamino il metodo setName (), tuttavia deve essere pubblico perché il messaggio e la classe per rappresentare una connessione sono in pacchetti diversi. Mi piacerebbe sapere se è una buona forma deprecare il metodo con un motivo sulla falsariga di "solo per uso interno", e in caso negativo, qual è l'opzione migliore?

    
posta john01dav 09.04.2015 - 20:02
fonte

1 risposta

3

Potrebbe essere necessario prendere in considerazione il ri-factoring.

Quindi sembra che abbiamo [Client] -messaggio- > [Server] e Message (e tutte le derivate di) sono memorizzati nel pacchetto [Common]. Nel tuo commento spieghi che il messaggio contiene una funzione che viene chiamata dal server o dal client a seconda di chi ha ricevuto il messaggio, che a sua volta chiama un metodo sul client o sul server.

Ai miei occhi, e solo da quello che posso ricavare dalle tue spiegazioni, è che dovresti considerare di scrivere i meccanismi di gestione dei messaggi direttamente nelle porzioni client e server invece di includere la gestione dei messaggi come parte della classe messaggio.

    
risposta data 09.04.2015 - 20:23
fonte