Se la funzionalità non fa parte dell'API della libreria, non dovresti usarla. Non c'è alcuna garanzia che sarà ancora disponibile nelle versioni future e che non cambierà. Quindi utilizzare la riflessione per accedere agli interni è una strategia di ultima istanza.
È spesso ragionevole dare un fork alla libreria e aggiungere questa funzionalità da soli. È quindi possibile offrire una richiesta pull al progetto upstream, in modo che le modifiche possano far parte di una futura release mainstream. Questa strategia è preferibile perché il tuo cambiamento sarà supportato dal progetto upstream. Ma questo funziona solo se il tuo cambiamento si inserisce nella visione del progetto, ad es. nessuna drastica espansione dell'ambito. Cambiare semplicemente un metodo da privato a pubblico non è probabilmente un cambiamento accettabile. Questo è un hack . Invece, valuta come la biblioteca dovrebbe essere progettata per affrontare il tuo caso d'uso.
Se il progetto upstream non accetta il tuo suggerimento, puoi comunque mantenere la tua forcella. Tuttavia, questo rende difficile tenersi aggiornati con gli aggiornamenti. Questo è particolarmente problematico per gli aggiornamenti di sicurezza. Nel corso del tempo, la fusione a monte delle tue modifiche diventerà sempre più difficile man mano che divergono. Si prega di considerare se è possibile impegnarsi per il mantenimento di questa forcella, e quindi portare questo rischio.
Per le modifiche che sono utili solo a te, fornisci tale funzionalità come una classe o una libreria completamente separate. Se la libreria originale è concessa in licenza in modo appropriato, è possibile riutilizzare parti rilevanti del codice sorgente. Copiare semplicemente un'intera lezione e modificare alcuni dettagli non è probabilmente di aiuto. Invece, guarda questo codice sorgente come punto di partenza per il tuo progetto.