Měli konstruktor inicializovat vlastní parametry přímo do neveřejné člena nebo prostřednictvím veřejné oblasti (C # centric)?

hlasů
4

Například, jakým způsobem je lepší

class Foo {
private string _Bar ; 
  Foo ( string bar)
  {
    _Bar = bar ; 
  }
 public string Bar 
 { 
   get { return _Bar ; //more logic here
   } 
   set { _Bar = value ;   //more logic could be added
  }
 }
}

NEBO

class Foo {
private string _Bar ; 
  Foo ( string bar)
  {
    this.Bar = bar ; 
  }
 public string Bar { 
  get { return _Bar ; //more logic could be added } 
  set { _Bar = value ; //more logic could be added }}
}

Edit: Já vím, že tento umožňuje dát nějaký větší logiku v tom, ale je to ospravedlnitelné ji používat, protože to ...

Položena 20/05/2009 v 18:12
zdroj uživatelem
V jiných jazycích...                            


7 odpovědí

hlasů
6

Podle toho, jak smysl pro třídu; není tam žádný „best practice“.

Někdy možná budete chtít, aby zajistily, že jste jen provádět stejné operace vlastnost silách; v takovém případě má smysl použít vlastnost.

Někdy chcete dělat věci, které lze provést pouze v konstruktoru, které porušují věci, které můžete udělat pomocí vlastností po konstrukci, přičemž v tomto případě má smysl pouze na nosítkách.

Odpovězeno 20/05/2009 v 18:16
zdroj uživatelem

hlasů
1

I často používají vlastnosti, protože mi umožňuje psát jen můj ověření na jednom místě (vlastnost setter). To pomáhá vyhnout se duplicitní kód.

public class Foo
{
   private string _Bar = String.Empty;

   public string Bar
   {
      get { return _Bar; }
      set 
      {
          if (value == null)
             throw new ArgumentNullException("Bar");
          _Bar = value;
      }
   }

   public Foo(string bar)
   {
      Bar = bar;
   }
}
Odpovězeno 20/05/2009 v 18:28
zdroj uživatelem

hlasů
1

Záleží na tom, jestli budete potřebovat logiku ve veřejném vlastnictví, které mají být provedeny, použijte tuto metodu. Pokud jste právě dělá přímý úkol, a pak zařadí do soukromého členu je v pořádku.

Odpovězeno 20/05/2009 v 18:16
zdroj uživatelem

hlasů
1

Záleží.

Dávám přednost pomocí vlastností, když nejsou tam žádné vedlejší účinky. Existují však situace, při nastavování vlastnosti má i další vedlejší účinky, jako je oznámení události, potenciálně zbytečné (na tomto místě) validace, etc. V takových případech nastavení podkladová pole přímo je lepší volba.

Odpovězeno 20/05/2009 v 18:16
zdroj uživatelem

hlasů
0

Dám nějaké maso na mém „Záleží“ odpověď: budete se snaží najít rovnováhu mezi ujistěte se, že vnitřní stav zůstává konzistentní, duplikace kódu, a výkon.

Souhlasím w / Adam P, protože vaše aktuální příklad je velmi jednoduché to opravdu nezáleží.

Vezměme si příklad, kde je jen pro čtení Proměnná Qux je závislá na baru a dalším členem Baz. Qux je poměrně nákladná počítat, takže byste nechtěli, aby to v reálném čase - což naznačuje, vlastní pole pro uložení stavu, a změnit jej IFF Bar a Baz změnu.

Takže v konstruktoru můžete nastavit bar a Baz veřejně, s vědomím, že Qux budou vyřešeny dvakrát, nebo odložit řešení Qux do konce konstruktoru (a uložit jeden rozlišením volání Qux).

V poměrně triviální kódu, který je pravděpodobně nezmění (např veřejné vlastnosti doprovodné jednoduché soukromé pole), vybrat jeden styl, držet se ho, a soustředit se na řešení vašich programů reálných problémů.

Odpovězeno 20/05/2009 v 20:16
zdroj uživatelem

hlasů
0

Váš příklad je příliš jednoduché, ale váš komentář „// by mohlo být přidáno více logika“ se zmiňuje o možnosti, že nastavená vlastnost by mohla být složitější než jednoduché přiřazení k soukromé proměnné.

Neopakujte stejnou logiku v konstruktoru, pokud jste již kódovány stejnou logiku v sadě vlastností. To by bylo zbytečné duplicitní kód a může být náchylné k chybám, když logika musí změnit a bolest v krku pro vývojáře v budoucnosti, který má udržet svůj kód.

Pokud váš soubor vlastnost má nějaké vedlejší účinky, které by bylo nežádoucí / nepotřebné v konstruktoru jako oznámení události, pak byste měli refaktorovat společný kód na své vlastní metody. Konstruktor a nastavit vlastnost lze oba volat tuto metodu.

Budeš mít spoustu „záleží“ odpovědi, protože, no, to záleží. Některé z důvodu, který bude osobní preference (často určuje minulých zkušeností, kde něco bylo těžké udržet nebo kočárek). Některé z důvodů, proč to, že každá situace je jiná, a zatímco tam je určitě spousta společných vzorů a úkolů provádíme s kódem vždycky musí mít možnost nesleduje normu být kreativní a inovativní ve svých kódujících řešení vašich problém. Zapamatovat nemáme programový kód, můžeme naprogramovat řešení pomocí kódu jako nástroj.

Odpovězeno 20/05/2009 v 19:01
zdroj uživatelem

hlasů
0

Přečtěte si tento skvělý blog post Eric Lippert: Automatické vs explicitní Vlastnosti :

Zde je otázka, loni jsem dostal od uživatele C #, je otázka, mám poměrně často:

Uživatel: S „regular“ explicitní vlastnostmi, mám tendenci používat vlastní doprovodnou pole přímo z třídy. Samozřejmě, s automatickým majetku, můžete to udělat. Obávám se, že v budoucnu, pokud se rozhodnu, že je třeba výslovně majetek z jakéhokoli důvodu, jsem odešel s výběrem mění implementaci třídy použít nový vlastní pole, nebo pokračovat prochází majetku. Nejsem si jistý, co je správná věc dělat v tomto případě.

Říkáte, že „z jakýchkoliv důvodů“, a to je klíčové. Odpověď na vaši otázku bude zcela záviset na tom, co bylo důvodem, která motivovala změnu.

Je-li důvodem, která motivovala změna oproti automaticky implementována vlastnost výslovně implementována vlastnost byla změna sémantiku majetku pak byste měli posoudit, zda požadovaná sémantika při přístupu vlastnost zevnitř třídy jsou identické nebo odlišné od požadovaných sémantiky při přístupu vlastnost zvenčí třídy. [důraz důlní]

Odpovězeno 20/05/2009 v 18:27
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more