¿Hay alguna razón para no usar las propiedades 'protegidas'?

Question

Solo preguntando ...

¿Hay alguna razón para no usar las propiedades protegidas?

quiero decir en lugar de utilizar esto:

public abstract class Foo 
{ 
    protected Bar { get; private set; } 
} 

de usar éste:

public abstract class Foo 
{ 
    private Bar _bar; 

    protected Foo(Bar bar) 
    { 
     _bar = bar; 
    } 

    protected GetBar() 
    { 
     return _bar; 
    } 
} 

Answer 1

No veo ninguna razón por la que utilizaría un método en lugar de una propiedad independientemente de GetXXX() son modificadores.

Dado que etiquetó esta pregunta con la etiqueta C#, recomiendo estrictamente usar la primera aproximación. Para eso están las propiedades.

Utilice un método solo cuando el valor devuelto por él puede ser diferente cada vez que lo llame, independientemente de su estado. Por ejemplo, DateTime.Now fue un error y debería haber sido un método.

Para obtener más información, consulte la propiedad Usage Guidelines on MSDN. En una nota lateral, es sorprendente cómo no han tenido la necesidad de cambiarlo desde Framework 1.1.

Answer 2

Sólo si tiene atributos no modificables o no legibles dentro de la clase

Answer 3

Unas cuantas más razones para usar propiedades en lugar de los métodos: la unión

• datos sólo se pueden ver las propiedades
• Usted puede usar semántica solo lectura o solo escritura.

Answer 4

La pregunta no es realmente acerca de protected tiene más con: ¿por qué debería usar propiedades?

Propeties son lógicamente equivalentes con Getter pares de método/organismo, lo que puede hacer con un con un Name {get{} \ set{}} que puede hacer con un GetName() \ SetName() par y viceversa, especialmente en lo que C# tiene get y set descriptores de acceso, por lo que pueden jugar con el accesibilidad también

Pero, hay algunas personas que sienten que las propiedades públicas (o protegidas) son un poco como copiar desde una perspectiva OOP, especialmente si todo lo que hace la propiedad es simplemente exponer un campo de respaldo. Después de todo, person.Name = "SWeko" parece que cambia el estado del objeto externamente, mientras que person.SetName("SWeko") simplemente le dice al objeto que necesita cambiar su estado. Y desde un punto de vista puramente teórico, creo que esas objeciones tienen sus méritos.

Sin embargo, no todos tenemos el lujo de vivir en torres de marfil, por lo que el concepto de propiedades es realmente útil, ya que es más legible, menos propenso a errores y en mi humilde opinión, más cercano al modelo real. También nos proporciona una especie de dicotomía, cuando escribo algo como esto:

person.Name = "SWeko"; 
person.Work(); 

espero que la primera línea será una tarea rápida, y no tienen efectos secundarios, mientras espero que la segunda línea hará algo más, y probablemente afecte el estado interno del objeto.Cuando uso el método Getter y Setter, ninguna distiction es inmediatamente obvia:

person.SetName("SWeko"); 
person.Work();