privados - protected php
¿Es mejor utilizar métodos privados o métodos protegidos? (10)
En muchos de mis proyectos PHP, termino con clases que tienen funciones no públicas que no pretendo extender.
¿Es mejor declararlos como protegidos o privados?
Puedo ver argumentos en ambos sentidos: hacerlos privados es un enfoque mucho más conservador, pero se puede argumentar que podrían protegerse más adelante si quiero que el método se extienda y deja en claro qué métodos se extienden por clases base.
Por otro lado, ¿usar privado de alguna manera antisocial, en la medida en que impide que un futuro desarrollador teórico extienda mi código sin modificaciones?
Bueno, la palabra clave privada fue pensada con un propósito. Si no quiere que las variables llenen sus clases heredadas (o no quiere que la gente juegue con ellas en clases heredadas), ¿por qué siquiera considera protegerlas?
No dejes que la gente toque tus partes privadas :)
Creo que solo debes exponer lo que necesites cuando lo necesites. Esto hace que sea más fácil hacer evaluaciones de impacto de los cambios. es decir, si un método es privado, usted sabe que el impacto será mínimo si lo cambia.
Declararía los métodos como privados. Indica claramente que no son parte de la API pública.
No te preocupes por lo que pueda suceder en el futuro.
Mi instinto es mantenerlos en privado, hasta que necesites que sean de otra manera.
Se ha argumentado (lamentablemente he perdido el enlace) que hacer que los métodos sean privados es antisocial, de la misma manera que los hace ''finales'', ya que es bastante dictatorial sobre cómo las personas pueden usar su código.
Sin embargo, no estoy convencido y estoy de acuerdo en que debes exponer solo lo que realmente necesitas. La excepción sería una biblioteca o conjunto de herramientas, donde esperará que los usuarios quieran extender (en sentido general) su código de una manera que nunca previeron. En cuyo caso, proteger los métodos bien seleccionados puede verse como un punto flexible.
Personalmente, considero apropiado hacer todo lo que sea posible en privado. Solo miro cada método y me pregunto si quiero que una clase derivada pueda llamarlo. Hacer que todo esté protegido deja abierta la puerta para que se llamen incorrectamente los métodos.
Supongo que todo se reduce a las preguntas "Está todo prohibido a menos que se permita específicamente" o "Todo está permitido a menos que se prohíba específicamente".
Un factor adicional es que es fácil hacer que un método privado esté protegido en una versión futura. Es casi imposible privatizar un método una vez que está protegido, ya que nunca se sabe qué otro código invalida.
Si la función que ha implementado es específica de una clase y no debe usarse fuera del contexto de esa clase, no permita que se herede. Por ejemplo, si tuviéramos una jerarquía de animales, y uno de los animales tuviera algo increíblemente exclusivo para ellos solamente, diga "layEggsInSand ()" como una tortuga. Esto puede ser totalmente exclusivo de la tortuga (¡tortuga, lo que sea!) Por lo tanto, no debe ser heredado por ningún otro animal. En este contexto, diríamos que es privado. Por otro lado, si la función es "caminar ()", no es única, por lo tanto, debe ser heredable.
Parece bastante confuso al principio porque la mayoría de las veces las cosas deben heredarse, pero hay casos más raros en que no deberían heredarse ya que son únicas para ese tipo.
Si tiene la intención de crear una clase para la herencia, debe diseñarla de esa manera, es decir, proteger esos métodos para permitir que otros desarrolladores modifiquen el comportamiento de la clase según las líneas que se proponen. Simplemente proteger todos los métodos no es un buen diseño. Tenga en cuenta que todos los métodos protegidos se vuelven parte de la API pública, por lo que si cambia las cosas más adelante, romperá el código de otras personas.
En general, si no está diseñando para herencia, debe prohibirlo.
Generalmente evito los private . Mi razonamiento es que si tienes una relación de herencia entre dos clases, y hay miembros privados, entonces es un indicativo muy fuerte de que debes factorizar las partes privadas en un objeto separado.
Como se dijo, si va a extender una clase más tarde, siempre puede cambiarla.
Pero si puede evitar el uso de la herencia, debería hacerlo. Es mejor usar otros patrones al diseñar, si es posible.
Básicamente, qué hacer es favorecer la composición sobre la herencia y el programa a las interfaces, no a las implementaciones.
Si permite que las clases solo tengan un propósito estrictamente definido, puede componer objetos en lugar de dejar que se hereden entre sí. Si usa interfaces en lugar de herencia, lo más probable es que defina interfaces pequeñas y efectivas. Entonces verá que la herencia se reducirá y, por lo tanto, la necesidad de protección se reducirá a.
Ejemplo
interface sound {
public function makeSound();
}
class bark implements sound{
public function makeSound() {
return "Bark!!!";
}
}
class mew implements sound{
public function makeSound() {
return "Mewmew!!!";
}
}
class forLeggedAnimal {
private $sound;
public function forLeggedAnimal($sound){
$this->sound = $sound;
}
public function eat(){
echo $this->sound->makeSound();
}
}
$cat = new forLeggedAnimal(new mew());
$dog = new forLeggedAnimal(new bark());
Sé que esto está lejos de ser un ejemplo perfecto. Pero ilustra la técnica y puedes usar esto de muchas maneras. Por ejemplo, puedes combinar esto con diferentes patrones de creación para construir gatos y perros, puede que no sea tan inteligente saber si un gato ladra o ladra ... Pero de todos modos ... difiere de tener que hacer una clase base y luego extender con un gato y un perro, y por lo tanto tiene que hacer que el método de "sonido" proteja o anule el método público de comer
/ Peter
Generalmente uso privado en alguna ocasión muy específica donde el método / variable es muy interno y no debe ser leído o escrito por ninguna otra subclase (básicamente, casi nunca). El único caso en mente donde uso la variable privada es por ejemplo:
final public function init():void
{
if(!_initialized)
{
_init();
_initialized = true;
}
}
protected function _init():void
{
// specific code.
}
En la mayoría del otro caso, los métodos y la variable deberían ser útiles para la herencia, al menos como una función de lectura. Porque la mayoría de las veces cuando uso código creado por otra persona, y cuando este código usa cosas privadas, siempre y con muchos problemas:
- el comportamiento deseado aún no está implementado o completo
- No puedo usar un método porque es privado
- No puedo cambiar este método porque es privado
si está protegido (o si lo cambio como protegido), entonces no puedo volver a trabajar el código (es decir, agregando comportamientos entre otras instrucciones, porque parte de este código usa métodos o variables privados ...).
= en los extremos, casi cambias todo el acceso a protegido para obtener la capacidad de extender la clase.
Por lo tanto, si crees que esta clase se puede ampliar, se prefiere proteger para todo excepto en casos muy específicos (si crees que un método específico solo se debe usar pero no cambiar, usa protección final).
Si crees que esta clase no debe extenderse en ningún caso: usa privado.