¿Por qué las personas a menudo omiten público/privado/protegido al declarar una clase?

Question

Sigo viendo este formato en los últimos códigos e incluso aquí:

class Class { 
    function this() {} 
} 

en lugar de

class Class { 
    [public/private/protected] function this() {} 
} 

1. ¿No es recomendable para siempre especifique el ámbito de la función?
2. ¿No es el primer enfoque uno antiguo?
3. ¿Cómo se definen, en el primer enfoque, funciones privadas y protegidas ?

Answer 1

Cuando se declara una función sin ninguna palabra clave que es pública por defecto.

¿No se recomienda especificar siempre el alcance de la función?

Debe definir el alcance de la función si va a utilizarlas como privadas o protegidas.

¿No es el primer enfoque uno antiguo?

¿Qué es lo viejo y lo nuevo si todavía son aceptados por PHP.

¿Cómo están, en la primera aproximación, definido privada y protegida funciones?

No se puede, con el primer enfoque, tiene que usar palabras clave.

Answer 2

1. Sí, probablemente.
2. Es difícil cuantificar qué tan nueva o vieja es una técnica. Pudo haber sido menos no recomendado en el pasado, cuando las clases eran relativamente nuevas en PHP.
3. "Class methods may be defined as public, private, or protected. Methods declared without any explicit visibility keyword are defined as public."

Answer 3

PHP nació como un (perezoso, duck typed) lenguaje de scripting, y las personas todavía lo usan de esta manera. La mayoría de los programadores PHP no tienen una idea de lo que es el OOP, conozco muy bien este problema porque comencé con PHP, y eso me costó mucho trabajo más adelante. Aproximadamente el 90% del código PHP que ves es desordenado y desactualizado en cuanto a orientación de objetos, legibilidad, encapsulado, etc. Al menos el 50% es pura basura. :(

No puedo decir cuánto están sorprendidos programadores de POO cuando descubren que "inyección de dependencias" en realidad se considera un patrón de diseño innovador por los desarrolladores de PHP, y tiene que ser explicado.

Sin embargo, PHP4 no tenía operadores de ámbito tales como privado o protegido. En ese momento, solía declarar un método que anteponía uno o más guiones bajos al nombre del método para indicar que no se debe invocar desde clases externas.

1. Sí se recomienda
2. Sí lo es, en una perspectiva de programación orientada a objetos
3. Convenciones de nombres que se espera que tuvieron que ser entendidas por los clientes

Answer 4

1. Si lo es. Siempre se recomienda especificar la visibilidad de la función/propiedad.
2. Sí lo es. La versión sin modificadores de visibilidad ha existido hasta PHP4. Con PHP5 se introdujeron modificadores de visibilidad. Debido a la compatibilidad con versiones anteriores del código heredado, la versión sin modificadores de visibilidad todavía se acepta y trata como si hubiera un modificador de visibilidad public.
3. PHP4 no sabía nada acerca de la visibilidad, por lo que no puede definir private o protected miembros con esta sintaxis de modificador de visibilidad.

Answer 5

Compatibilidad y afinidad de PHP4 por delante.

Algunos desarrolladores (como yo) omiten los modificadores de accesibilidad porque tienen poca relación con los lenguajes de scripting. Los lenguajes de OOP reales como Python o Javascript no tienen los atributos private o protected, y no los necesitan. En PHP es un poco diferente, pero no tiene sentido que siempre aplicar ese azúcar sintáctico. Yo personalmente haré un punto para reservarlo para aplicaciones útiles.

Muchos codificadores PHP desconocen el propósito original de "encapsulación", ya que no se aplica al código no compilado más allá de la visibilidad lógica. De hecho, agrega un poco más de fragilidad en PHP, ya que explota los errores en tiempo de ejecución, en lugar de tiempo de compilación (como en C++).
Y no puedo dejar de repetirlo: muchos codificadores también lo aplican únicamente como cargo cult programming idiom para simular la sintaxis similar a Java (para compensar la falta percibida o pasada de constructos OOP de PHP).

Answer 6

El estándar de codificación PSR-2 requiere explícitamente el modificador de visibilidad para ser utilizado tanto para properties como para methods.

No es necesario utilizar public porque PHP 5 y 7 son compatibles con la versión 4, que solo tenía visibilidad pública para todo, por lo que es la configuración predeterminada.

Sin embargo, omitirlo generará preguntas, como usted. Los humanos son muy buenos para detectar patrones y errores en los patrones. ¿Qué pensaría de un fragmento de código que utiliza protected o private en todas partes (porque es necesario), pero omite aleatoriamente public. ¿Es esto un error? Ha sido hecho intencionalmente? ¿Qué tipo de comportamiento secreto se supone que se desencadenará por esto? ¿O todavía es un código PHP4 que oculta algunos desagradables problemas de compatibilidad? Como desarrollador, no quiere hacer estas preguntas, y no quiere tener que encontrar las respuestas.

public es opcional, pero el PSR-2 decidió requerirlo. Ve con la recomendación estándar.

También tenga en cuenta que ha habido a proposal to deprecate and remove the var modifier para propiedades y reemplácela por completo con public.La propuesta también enumera un análisis de código de los 10,000 mejores paquetes en Packagist, indicando que el 94% de todas las clases en esta base de código usa public exclusivamente, el 6% restante de las clases que usan var provienen de cuatro paquetes más grandes que probablemente aún lo intenten ser compatible con PHP4, con "Simpletest" (un marco de pruebas unitarias dirigido a PHP 4) a la cabeza.

No existe este tipo de análisis de código estático para los modificadores de visibilidad de los métodos que conozco, pero la tendencia es claramente visible: Deshágase de los viejos PHP4-ismos.