¿Por qué es tan importante la protección pública privada?

Question

La gente me sigue diciendo que debería usar modificadores de acceso públicos, privados o protegidos frente a todas mis propiedades y métodos de clase. Realmente no entiendo por qué. Soy nuevo por lo llevo conmigo, pero la forma en que lo veo es esto:

• yo soy el único que va a trabajar en mi código. No es un equipo

• Ya sé lo que significa todo, además de usar un editor que me dice todos los valores y propiedades declarados, sé que no voy a pisar mis variables usadas.

Una de las explicaciones que se ve es que "protege u oculta" su código de personas que pudieran verlo ..... pero en PHP que no hay manera que yo sepa para un usuario para ver su código en primer lugar, ¿de quién estoy escondiéndolo? Si PUEDEN ver mi código, entonces son piratas o están en mi cuenta, así que no puedo detenerlos de todos modos.

Entiendo si estaba trabajando con un gran código en un equipo, pero para cosas pequeñas parece innecesario.

Answer 1

No está "ocultando" su código a nadie, eso no tiene sentido.

Lo protected y private propiedades están haciendo es decirle a PHP cómo va a utilizarlos. Cuando creas una clase, generalmente debes tener una idea de cómo quieres que se use esa clase. Tendrá public partes, con las que otro código puede interactuar, y otras partes que no quiere que tengan otro código de acceso directamente. Normalmente, desea restringir las partes public de una clase a un conjunto muy pequeño de métodos bien definidos que no van a cambiar. Porque una vez que los utilizas en otras partes de tu código, cambiarlos se convierte en un dolor. Todas las cosas private y protected solo deben ser accedidas dentro de la misma clase, por lo que cambiarla no será un problema más adelante.

Si eres el único que trabaja en el código, puedes decir que es tan fácil como simplemente no usar las "partes privadas". Pero vas a cometer errores y vas a olvidar qué parte pertenece a lo largo del tiempo. Al marcar explícitamente estas propiedades como protected o private, PHP puede ayudarlo a no violar sus propios "términos de uso". Es la diferencia entre una nota mental de "no tocar esto" y de hecho ponerle un candado a algo.

Answer 2

"Encapsulación", como se llama, no protege su código de las personas. Cualquiera que tenga acceso a tu código fuente ya sabe lo que hay allí. Y si no tienen la fuente, tampoco pueden hacer nada especial con tus cosas públicas.

Lo que hace es evitar que el código que no está en la clase (y por lo tanto no debería saber cómo la clase hace las cosas) se detenga accidentalmente con variables internas. De esta forma, es menos probable que las variables terminen con valores absurdos, y cuando lo hagan, puede señalar a la clase y decir que el código roto es allí, en lugar de a medio camino de la aplicación.

Nota, para que esto sea útil en absoluto, no puede tener trivial setters para todo, como public function setX($x) { $this->x = $x; } - que vence todo el propósito. Su objeto debe ser tanto como una "caja negra" como pueda hacerlo, y eso en parte significa que el código externo debería poder ver y modificar la menor cantidad posible de su estado interno. Deje que la clase administre su propio estado, y tenga métodos que tomen las otras cosas que necesitan para hacer su trabajo. (Una excepción semi-obvia aquí serían los tipos cuyo propósito principal es transportar datos, pero incluso allí debe limitar el acceso a cualquier cosa que no sea esa información, y los instaladores de tales datos lo validarían idealmente y tal).

Answer 3

He encontrado que los operadores lo ayudan a no pisar su propio pie. A medida que mis aplicaciones se han hecho más grandes, a veces he perdido de vista mis pensamientos originales al hacer algunas de las clases anteriores y ha sido útil tener los modificadores de acceso para protegerme. También ayuda a organizar mejor su código para que comprenda qué es qué y no termine programando código de espagueti. Además, en caso de que termine programando para otra persona algún día en una situación en la que alguien pueda ver su código más adelante, no se sentirá avergonzado por su estilo de codificación ya que se acostumbró a usar los constructos de el lenguaje para estructurar su código lo ayudará a mejorar su estilo de codificación. Los constructos están ahí, entonces ¿por qué no usarlos?

Así que para su situación específica en este momento, diría que todo lo que está haciendo en este momento es esconderlo de su futuro para que no sea como "Hmm ... hice esta clase para uno de mis proyectos Hace 2 años y lo usaré ahora "y luego voy a tratar de meterme con las partes internas de una manera en la que no deben ser manipuladas, lo que podría causar problemas por una razón que quizás no puedas recordar.

Es cierto que, a menos que trabaje con un lenguaje compilado como C# o C++, los modificadores no ocultarán su código real a un posible usuario final. Cuando crea una biblioteca en ese tipo de idiomas, los modificadores se vuelven más importantes porque ocultan su código al usuario final y si termina trabajando en un sistema propietario que puede ser importante (aunque molesto para el usuario final a veces).

Answer 4

Lo principal es obligatorio para el código encapsulado y consistencia, por lo que tiene una interfaz coherente alrededor de su código.

Cuando está creando sus clases, está indicando qué partes quiere que sean públicas-privadas-protegidas, también piensa en el futuro y la arquitectura de cómo los datos deben interactuar con otras clases, y también es bueno para usar en proyectos pequeños

Si bien para los proyectos pequeños parece inútil, recomiendo comenzar a usarlo, y aumente su hábito de usarlos, cuando comience a usar modificadores de visibilidad verá que son bastante útiles.