¿Los miembros / campos protegidos son realmente tan malos?

Ahora, si lee las convenciones de nomenclatura en MSDN para C #, notará que establece que las propiedades siempre se prefieren a los campos públicos y protegidos. Incluso algunas personas me han dicho que nunca debe usar campos públicos o protegidos. Ahora estaré de acuerdo en que todavía tengo que encontrar una razón por la cual necesito tener un campo público, pero ¿los campos protegidos son realmente tan malos?

Puedo verlo si necesita asegurarse de que se realicen ciertas comprobaciones de validación al obtener / establecer el valor, sin embargo, en mi opinión, muchas veces parece una sobrecarga adicional. Quiero decir, digamos que tengo una clase GameItem con campos para baseName, prefixName y suffixName. ¿Por qué debería tomar la sobrecarga de ambos creando las propiedades (C#) o métodos de acceso y el impacto en el rendimiento que ocurriría (si hago esto para cada campo en una aplicación, estoy seguro de que sumaría un poco menos, especialmente en ciertos idiomas comoPHP o ciertas aplicaciones con rendimiento son críticas como los juegos)?

Respuestas a la pregunta(6)

Su respuesta a la pregunta