Al crear una biblioteca, ¿debo asegurarme de que los métodos privados deben funcionar como se espera cuando se los llama no por otros métodos de la misma clase, sino por otra biblioteca a través de la reflexión ?
Por ejemplo, si un método privado private DoSomething(int number)espera que:
numberes un número entero positivo distinto de cero y:- una variable privada
string abcno es nula y no es una cadena vacía,
y completamente, feo falla si esas dos condiciones no se corresponden, debo manejar esas fallas, incluso si sé que todos los métodos de la clase se always¹ asignar un valor no vacío a abcantes de llamar DoSomething, y pasar un entero positivo distinto de cero a esta ¿método?
En otras palabras, ¿el código que no está protegido contra llamadas inseguras a través de la reflexión puede considerarse como un código de baja calidad , o pertenece a la persona que llama que usa la reflexión para asegurarse de que la llamada no interrumpa nada?
Nota: mi pregunta cubre solo un conjunto estándar de bibliotecas. Esto no cubre el código que debe ser altamente seguro (es decir, cuando alguien puede estar interesado mediante el uso de la reflexión para que se comporte de forma inesperada o se bloquee).
¹ Porque la clase está documentada correctamente, porque hay suficientes pruebas unitarias para asegurarse de que cualquier otro desarrollador no rompa este método, etc.
fuente
Respuestas:
Al marcar su método como privado, estableció sus intenciones y un contrato. Al utilizar la reflexión, un código de cliente puede optar por romper con este contrato y, en consecuencia, tendrá que soportar las consecuencias. Lo mismo sucede con los protocolos, para que las cosas funcionen se deben seguir las reglas o sucederán cosas malas.
El mismo problema puede ocurrir con otros lenguajes como C ++ donde vi cosas como
En resumen: NO está obligado a lidiar con estas situaciones, la persona que llama debe saberlo mejor.
fuente
Si alguien está usando la reflexión para llamar a sus métodos privados, es una señal de que alguien está haciendo algo mal. O está usando el código de formas para las que no fue diseñado, o está ocultando demasiado el funcionamiento interno y estorbando la API.
Pero parece que aún no estás en esa etapa, y solo estás tratando de ser preventivo. Entonces mi opinión es: no te preocupes por eso. Un método privado debe considerarse fuera de los límites; Si alguien viola deliberadamente esos límites, entonces es su problema si las cosas explotan.
fuente
Bueno, siempre es una buena idea validar variables no locales antes de usarlas, pero aparte de eso, no me preocuparía. Como dijeron los demás, has establecido tus intenciones al hacer que el método sea privado en primer lugar; cualquiera que lo llame desde fuera de su clase tiene cero garantías. Cuando trabajo en Java, ni siquiera pongo comentarios javadoc sobre mis métodos privados, porque no quiero que otros desarrolladores sepan que están allí.
fuente