(C#) Mi a különbség a mezők és a tulajdonságok lentihez hasonló megadása között?

Van.

Míg az egyik esetben közvetlenül az attr.-nak adsz értéket, addig a { get; set; } esetén egy getter-setter metódus hívódik meg (ez esetben az attr. lehet private), ami beállítja az attr.-ot, attól függetlenül, hogy te az "Obj.Szam = xy" adod meg.

Továbbá a getter-setter metódust felül tudod írni, abban a blockban, hogy speciális dolgoz csináljon. pl. negatív szám helyett 0-t írsz be.

Bár annyira nem ismerem a C#-ot (inkább Java, PHP-s vagyok), de mikor tanultam valami ilyesmi maradt hátra. :)

Ezek szerint mégsem nagyon tudod.

Egyrészt van szemantikai különbség. A mező az, ami, felfedi az implementáció, míg a property elrejti.

Másrészt Property lehet része interface-nek, leszármazásnál felül lehet definiálni, ésatöbbi.

Publikus mezőket nagyon egyszerű mutable struct-ok és néhány nagyon speciáls eseten kívül soha sem érdemes használni.

"Ezek szerint mégsem nagyon tudod. "

Nem ezt kérdezte. Hanem azt, hogy amikor nincs megadva egy privát mező a property mögött, akkor mi történik. Ezt igazából én sem tudom. Ugye a szokásos eljárás:

private int mezo;

public int Mezo

{

get{ return mezo;}

set{ mezu = value;}

}

No de ha ÖNMAGÁBAN így használod:

public int Mezo{get;set;}

Na ilyenkor mi van? Ilyenkor ez gyakorlatilag egy mezőként viselkedik, a háttérben viszont nem tudom mi történik.

Ugyanaz, a különbség, hogy a mögöttes mező automatikusan generálódik ki.

A fent írt konkrét példában túlzottan sok funkcionális különbség nincsen, ami például kiemelhető, hogy a propertyt interface-ben is tudod deklarálni, míg a mezőt nem. Ezen felül ebben a konkrét formában nincs túl sok eltérés.

Igen, én is értem, hogy nincs különbség, teljesen tisztában vagyok a getter-setter metódusok értelmével meg használatával, én most a nyelv mögöttes logikájára lettem volna kíváncsi, mint ahogy a kérdező is. De hát akkor ezek szerint ilyenkor automatikusan generál egy mezőt.

Az interfaces dologért köszönet, ez még nem tűnt fel.

Tervezési, architekturális különbség van köztük. Ha majd a SOLID-ot és az enkapszulációt tanulni fogod, abban sokkal jobban ki van fejtve.

Röviden egy-két mondatban arról van szó, hogy komoly szoftvert nem osztályokban gondolkozva tervezel, hanem interfészeket hozol létre. Az, hogy az az interfész konkrétan hogy van implementálva, nem érdekes az őt felhasználó kód számára, neki azt kell tudnia, hogy ez egy olyan valami, ami csinál egy bizonyos dolgot, vagy szolgáltat valamilyen adatot. Ezért fontos például az, amit előttem is írtak, hogy interface-re nem tehetsz field-et, property-t viszont igen. Ha egy osztályszintű adat fontos az interfész szempontjából, akkor property-t csinálsz belőle. Ha csak az implementációhoz kell, private field-et hozol létre.

Példa:

interface IDogProvider

{

int NumberOfDogs { get; }

  Dog GetDobByName(string name);

}

Na most, ha fel akarod ezt használni egy osztályban, akkor elég annyit tudj róla, hogy ez egy kutyákat szolgáltató konstrukció. Teljesen mindegy, hogy adatbázisból szedi őket, memóriából, internetről, egy txt fájlból. A felhasználó kódnak ha van egy kutyaneve, az alapján vissza tud kapni egy kutyát, illetve meg tudja nézni, hogy hány kutya van összesen. Példa implementációk erre az interface-re:

[link]