Programación por usted

Question

Si está escribiendo algo usted mismo, ya sea para practicar, resolver un problema personal o simplemente para entretenerse, ¿está bien, de vez en cuando, tener un campo público? ¿Tal vez?

Answer 1

Déjame darte una analogía.
Vengo de una parte del mundo donde el inglés no es el idioma principal. Pero es necesario para todas las cosas en la vida.
Durante uno de esos días habituales durante mi adolescencia, dije algo muy gracioso en inglés. Entonces mi papá dijo: "Hijo, piensa en inglés. A continuación, obtendrá con fluidez "

Creo que se aplica perfectamente a esta situación.

Piense, intente y cuestione best practices en su patio de recreo. Pronto se dará cuenta de qué es lo mejor para qué. Por qué se necesitan propiedades en primer lugar. ¿Por qué debería ser esto público? ¿Por qué no debería llamar a un miembro virtual del constructor? Déjame intentar usar el modificador "nuevo" para una llamada a método. What happens when I write 10 nested levels of if-then-else and try reading it again after 10 days. ¿Por qué diablos debería usar un factory pattern para un proyecto simple? Etcétera.

Y entonces te das cuenta de sin disparar en el pie, ¿por qué los patrones de diseño son los patrones ...

Answer 2

Creo que es razonable si, conscientemente, tira el código después. En particular, si estás experimentando con algo completamente diferente, tomar atajos tiene sentido. Simplemente no permitas que conduzca a hábitos que se cruzan en el código "real".

Answer 3

Violar los principios generales es siempre "bien"! No es un error violar un principio, pero es una compensación. El costo de no escribir código limpio será mayor cuanto más tiempo sobreviva su software. Mi opinión sobre esto es: ¡si tienes dudas, hazlo limpio!

Answer 4

Por supuesto que está bien. Es su código, puede hacer lo que quiera con él. Personalmente, intento apegarme a las buenas prácticas también en mi código privado, solo para convertirlo en un hábito natural, así no tengo que pensar en ello.

Answer 5

La respuesta corta es sí, si crees que estás ganando mucho haciendo las cosas públicas en lugar de privadas con accesoras, puedes hacerlo. La consistencia, creo, es lo más importante a tener en cuenta. Por ejemplo, no haga públicas algunas variables, y otras no. Haga lo mismo en general si rompe con las mejores prácticas. Vuelve a una solución de compromiso. Casi nadie sigue muchas de las especificaciones de IEEE sobre cómo debe ejecutarse y documentarse la Ingeniería de Software porque la sobrecarga es demasiado grande y puede volverse inmanejable. Lo mismo es cierto para la programación personal y liviana. Está bien hacer algo rápido y sucio, simplemente no te acostumbres.

Answer 6

miembros públicos son aceptables en el Data Transfer Object design patter:

Típicamente, los miembros en Transfer Object se definen como public, eliminando así la necesidad de métodos get y set.

Answer 7

Una de las principales ventajas de OOP es la escalabilidad y la mantenibilidad. Al encapsular el código, uno puede ocultar la implementación. Esto significa que otros programadores no tienen que conocer la implementación y no pueden cambiar el estado interno de su objeto. Si tu idioma no admite propiedades, terminas con un montón de código que ofusca e hincha tu proyecto.Si el código no necesita ser trabajado por múltiples programadores, usted no está produciendo un componente reutilizable, y USTED es el programador de mantenimiento, luego, el código de cualquier manera le permite hacer las cosas.

¿Necesita una mucama hacer su propia cama por la mañana para practicar cómodamente hacer una cama?

Answer 8

nota

lateral: también depende del idioma:

En Scala, de acuerdo con el Uniform Access Principle, los clientes leer y escribir valores de campo como si son de acceso público, a pesar de que en algunos casos, en realidad están pidiendo métodos. El mantenedor de la clase tiene la libertad de cambiar la implementación sin forzar a los usuarios a realizar cambios de código.

Scala mantiene los nombres de campo y método en el mismo espacio de nombres.
Muchos lenguajes, como Java, mantienen los nombres de campos y métodos en espacios de nombres separados.
Sin embargo, estos lenguajes no pueden soportar el principio de acceso uniforme como resultado, a menos que incorporen soporte ad hoc en sus gramáticas o compiladores.

---

Así que la verdadera pregunta es:

Lo servicio que se expone (en este caso por tener un campo público) ?.

Si el servicio (obtener/establecer un valor de tipo de letra dado) tiene sentido para su API, entonces el "acceso directo" es legítimo.
Mientras encapsule ese campo eventualmente, ¿está bien porque hizo el acceso directo por el motivo "correcto" (API y exposición del servicio), frente al motivo "incorrecto" (acceso ad-hoc rápido).
Una buena prueba de unidad (pensando como el usuario de su API) puede ayudarlo a verificar si se debe acceder directamente a ese campo o si solo es útil para el desarrollo interno de otras clases dentro de su programa.

Answer 9

Aquí está mi opinión sobre ella:

1. aconsejaría evitando campos públicos. Tienen la desagradable costumbre de morderte más tarde porque no puedes controlarlos. (La palabra que está buscando aquí es volatilidad.) Además, si decide cambiar su implementación interna, debe tocar mucho más código.

2. Por otra parte, para eso están las herramientas de refactorización. Si tiene una herramienta de refactorización decente, eso no es tan difícil.

3. No hay una bala de plata. No puedo repetir esto lo suficiente. Si tiene trabajo que hacer y necesita hacerlo rápidamente, escribir una línea de código en lugar de ocho (como en el caso de Visual Basic) es ciertamente más rápido.

4. Las reglas estaban destinadas a romperse. Si una regla no se aplica necesariamente en su caso, no la use. Los patrones de diseño, las pautas de codificación, las leyes y las mejores prácticas no deben tratarse como una camisa de fuerza que requiera una complicación innecesaria del código hasta el punto en que sea enormemente complejo y difícil de comprender y mantener. No permita que alguien lo obligue a practicar solo porque es popular o "estándar" cuando no se ajusta a sus requisitos.

Una vez más, esta es una opinión subjetiva, y su kilometraje puede variar.