PHP restringe llamadas de métodos públicos

Estoy trabajando en una biblioteca que tiene bastantes clases que están unidas por una clase central. Esta clase central tiene que llamar a ciertos métodos en las otras clases para propósitos de configuración / configuración. Estos métodos tienen que ser públicos para que la clase central pueda llamarlos, pero no quiero que los usuarios llamen a estos métodos (ya que pueden causar un comportamiento no deseado).

Una sugerencia que hizo un amigo mío fue utilizar un constructor con parámetros para que la configuración se realice en el momento de la construcción. Para los propósitos de esta biblioteca, eso no es fácilmente posible. Las clases en cuestión están destinadas a ser ampliadas, y no quería imponer ningún requisito extraño en los parámetros del constructor si los usuarios quieren tener sus propios constructores. Aún más complicado es que parte de la información utilizada para la configuración no está disponible para el usuario. Tendría que ponerlo a disposición del usuario y confiar en que lo redireccionará a las clases adecuadas durante la construcción.

Actualmente, mi solución es prefijar estos métodos con algo y señalar a los usuarios que no llamen a métodos con dicho prefijo. Esto es lo suficientemente “flexible” como para permitirme agregar métodos más restringidos, pero aún asume que el usuario seguirá mis instrucciones. Tampoco es la más elegante de las soluciones.

Me preguntaba si había alguna manera de restringir estos métodos fácilmente. Pensé en agregarles una línea que verificara si era la clase central que los llamaba, pero tampoco parece ser la mejor solución.

Editar: debería explicar el propósito de esta architecture. Cada clase realiza una tarea particular en una stack de operaciones. El trabajo de la clase central es ordenar a una clase que realice su tarea, obtenga resultados y distribuya los resultados a las otras clases que los necesitan. Luego la clase pasa a la siguiente clase y hace lo mismo. Cómo se realizan las tareas depende de la clase extendida. Los métodos que quiero restringir son los que ayudan a la dispersión de los resultados. Espero que eso haga mis intenciones más claras.

Todo depende del rol de tu clase central. Según su descripción, parece ser una cola de impresión o una especie de progtwigdor. Si los objetos en spool son realmente creados por esa clase central, puede ocultar los objetos del cliente haciendo esos objetos privados, y luego crear stubs en el objeto central que le permite al cliente llamar a las funciones que usted permite.

Ej. (Código conceptual, podría no comstackrse realmente)

 class HiddenSubClass { public function MyFunc() { echo "hello"; } } class CentralClass { private $obj; function __construct() { $obj=new HiddenSubClass(); } function SubClassMyFunc () { $obj->MyFunc(); } } 

El cliente solo tiene el objeto CentralClass y, por lo tanto, solo puede llamar a SubClassMyFunc, pero no a MyFunc. La desventaja de esto es que esto también ocultará la estructura orientada a objetos de la biblioteca del cliente, que puede o no ser deseable.

Sin embargo, si los objetos son creados por el cliente y luego entregados a su clase central, hay muy poco que puede hacer para evitar que el propietario del objeto (el cliente) haga con él lo que quiera. El cliente puede llamar a cualquier cosa que su clase central pueda. Es posible que tenga que mover el código que desea proteger fuera de dicha clase, ya sea en “clases auxiliares” o en la clase central misma.

Editar: si quieres “piratearlo”, este sería un enfoque (aunque no lo recomiendo, porque es bastante mal):

Tenga un “secreto privado” en su clase central.

 class CentralClass { private $MySecret=42; function IsValidSecret($anumber) { return ($anumber==$this->MySecret); } } 

Ahora la clase central puede pasar $ MySecret como parámetro, cuando llama a cierta función “protegida” en los objetos en spool. Si CentralClass es un singleton, el objeto en spool puede llamar a ese singleton para verificar si el secreto pasado es correcto. Si CentralClass no es un singleton, tendrás que pasar ese objeto también.

 class MySpooledObject { function SuperSecretFunction ($asecret) { if (!$CentralSingleton->isValidSecret($asecret)) { die(); } } function SuperSecretFunction2 ($acentralobject,$asecret) { if (!$acentralobject->isValidSecret($asecret)) { die(); } } } 

Hay muchas variaciones de esto. La clase central podría establecer un indicador interno antes de llamar al método del objeto y restablecerlo a su regreso. En este escenario, el objeto puede preguntar a la clase central si ese indicador está establecido, y no es necesario pasar ningún secreto. Sin embargo, todavía necesitará $ acentralobject, a menos que sea un singleton.

    Intereting Posts