Przypadek ściągnięty ze stackoverflowa, ale obrazujący to co chcę pokazać:
public Background {
public Color Color { get; set; }
}
Jak zapatrujecie się na kwestię nazywania właściwości/pól w taki sam sposób jak nazwy klas? Często mam tak, że ciężko wymyślić inną nazwę, która z jednej strony nie jest taka sama jak nazwa klasy, a z drugiej dalej jest czytelna i będę mógł ją bez problemu zinterpretować za miesiąc.
Nie mam z tym problemów, tak samo jak .NET. Stosuję takie nazewnictwo i nawet nie zwracam uwagi na to, że nazwa "obiektu" jest taka sama jak nazwa klasy. Ot i przykład z życia: encja z nHibernate:
public class Mount
{
public virtual int Id { get; protected set; }
public virtual decimal MeasureCount { get; set; }
public virtual decimal ItemCount { get; set; }
public virtual Component Component { get; set; }
public virtual Measure Measure { get; set; }
public virtual Product Product { get; set; }
}
Trzy komponenty nazwane tak samo jak ich klasy. Zero problemów, a przynajmniej nie ma jakiejś magii w stylu np. notacji węgierskiej.
Jest to praktyka powszechna. Popatrz na przykład z dokumentacji tego ORM: https://github.com/jagregory/fluent-nhibernate/wiki/Getting-started#entities
public class Employee
{
public virtual int Id { get; protected set; }
public virtual string FirstName { get; set; }
public virtual string LastName { get; set; }
public virtual Store Store { get; set; }
}
NH to raczej profesjonalne narzędzie więc wiesz... Nie ma co się przejmować.
Moim zdaniem jeśli klasa mówi bardzo dobrze czym jest i co robi to nie ma sensu wymyślać innej nazwy. Bo po co?
Taka możliwość w .NET była chyba właśnie od początku z tego powodu dodana żeby nie trzeba było kombinować z dziwnymi nazwami tylko dlatego, że ktoś dobrze i jednoznacznie nazwał klasę, której używasz.
Dla mnie jest to dobry feature i pozwala się skupić na wykonaniu zadania, a nie na szukaniu synonimów dla nazwy pola.
Nie widze problemu aby tak nazywac wlasciwosci.
Dzięki, w takim razie mogę bez obaw to stosować :P