Avvisa sui metodi di terze parti proibiti

Naviga le tue risposte
8

Nota: questa domanda si riferisce al codice scritto in Java o C #.

Sto gestendo un paio di grandi progetti in cui abbiamo scoperto problemi (non necessariamente bug) con alcuni metodi di terze parti / SDK e ho scritto le nostre estensioni che invece dovrebbero essere utilizzate. Vogliamo che gli sviluppatori ricordino che l'utilizzo di questi metodi non è raccomandato per questo progetto.

Se avessimo usato le nostre librerie, potremmo facilmente rimuovere quel metodo o contrassegnarlo obsoleto / deprecato ma non possiamo farlo per le librerie che non abbiamo scritto.

Ad esempio, utilizziamo una libreria che ci fornisce due overload: 

acme.calculate(int quantity_, double priceInUsDollars_);
acme.calculate(int quantity_, string currencyCode_, double priceInCurrency_);

Vogliamo che gli sviluppatori utilizzino sempre il primo e ottengano il prezzo in dollari USA dai nostri sistemi di tassi FX standard. E sarebbe bello avere l'IDE (Eclipse / Visual Studio) avvisare gli sviluppatori quando usano il primo. Un avviso del compilatore sarà sufficiente.

Al momento, così com'è, dobbiamo affidarci ai revisori del codice per individuare tali errori e, come potete vedere, non è un approccio affidabile.

Un possibile modo in cui sono pronto ad andare è scrivere il mio check in stile check ( link ). Ma mi stavo chiedendo se ci fosse qualcosa di semplice che potrei usare. Qualcuno sa dei modi per ottenere un avviso IDE / compilatore del tipo che ho descritto?

Le soluzioni di IDE / compilatore non sono le benvenute.

    
posta Apoorv Khurasia 14.06.2012 - 15:59
fonte

4 risposte

7

Utilizzando uno strumento come NDepend / JavaDepend , potresti scrivere query CQL personalizzate per generare avvisi per questi casi molto specifici.

Hai detto nella domanda che volevi che l'IDE / il compilatore avvisasse gli sviluppatori. Penso che poiché NDepend / JDepend si integrano strettamente con l'IDE, questo potrebbe risolvere il tuo problema.

    
risposta data 14.06.2012 - 16:54
fonte
4

Il "white list approach": scrive una libreria wrapper nella libreria con essenzialmente le stesse firme dell'interfaccia della stessa lib, ma tralascia le funzioni proibite. Il wrapper deve delegare ogni chiamata al metodo alla chiamata della libreria corrispondente. Quindi lascia che i tuoi sviluppatori usino / link solo a quel wrapper invece della lib originale. Il wrapper potrebbe anche essere un buon posto per le estensioni della tua libreria.

Di coure, questo potrebbe diventare poco pratico se la lib ha una API molto grande con diverse centinaia di funzioni. Quindi vuoi implementare un "black list approach" come la soluzione "check style" che hai suggerito.

    
risposta data 14.06.2012 - 16:05
fonte
2

Uno dei vantaggi di Java Reflection è la possibilità di modificare le proprietà del metodo in fase di runtime. Uno degli usi è rendere pubblico un metodo privato, per essere in grado di usarlo comunque. Potrebbe funzionare molto bene al contrario, rendendo i metodi indesiderati privati, in fase di runtime. Anche se non sarà visto alla compilazione, sarà visto non appena il progetto sarà testato.

Questo articolo mostra come modificare le proprietà dei metodi in fase di esecuzione. Ecco la parte interessante: 

Class theClass = MyClass.class;
Class[] paramTypes = { Integer.TYPE, String.class };
Method method = theClass.getDeclaredMethod("myMethodName", paramTypes);
method.setAccessible(false); // this makes the metod private
System.out.println("Making method  myMethodName(int,String) private");
    
risposta data 14.06.2012 - 16:42
fonte
0

We want developers to remember that using those methods is not recommended for this project.

Poiché in alcuni casi dovevi già creare metodi di sostituzione. Vorrei creare una classe wrapper per l'intera libreria e utilizzare solo la classe wrapper.

Se la libreria è aggiornata, dovresti comunque aggiornare il tuo codice. La classe wrapper è abbastanza semplice da aggiornare.

Evita agli sviluppatori di utilizzare il metodo sbagliato anche se .... oserei dire che uno sviluppatore dovrebbe essere in grado di ricordare quali metodi non suppone di usare.

    
risposta data 14.06.2012 - 18:18
fonte

Leggi altre domande sui tag

Che cosa può o non può fare Garbage Collector? THREAD: thread del kernel rispetto ai thread supportati dal kernel rispetto ai thread a livello utente?