Väljer att fortsätta den tråd som skapades från http://www.pellesoft.se/communicate/forum/view.aspx?msgid=273187&forumid=128&sum=0#273216

Där Skrev jag bl a:

"
När jag själv pluggade hatade jag att behöva skriva properties om o om o om igen...
iom vs 2005 kom code snippets som hjälpte lite. Ex på
http://www.pellesoft.se/communicate/forum/view.aspx?msgid=238677&forumid=47&sum=1#272898

iom c# 3.0 kom så det jag eg eg önskade när jag pluggade och hade dessutom diskussioner med kursare om att en då ny version av c#-språket borde stödja detta...
(nej tyckte kursaren då)
Idag tror jag inte ngn c#:are ogillar automatiska properties?... inte ens kursaren

"

[Johan Normén]

"Idag tror jag inte ngn c#:are ogillar automatiska properties?... inte ens kursaren "

Jag har delade meningar ang dem. Som älskare av DbC (Design by Contract) så tycker jag det är vansinnigt med automatiska properties. Då jag gärna vill att man skall ha validering på sina sets. Men underbar i andra fall då man slipper skriva sättningen och hämtningen och dess privata variabel... Bara en parantes... Men de öppnar upp nya problem istället då risken finna att man tänker till för lite och istället av den elaka latheten hoppar över valideringarna som bör finnas där i många fall.

mvh Johan "


[Fredrik Normén]
"
Vad är skillnaden mellan ett publikt fält och automatiska properties om både get och set är public? Erik Gunners som va med och grundade C# skrev en intresant post om detta för många årsedan.. där han inte såg någon spec. skillnad.

Det är enkelt och smidigt att använda dom, men det kan leda till skapandet av förmånga mutable klasses.

Finns ett bra stycke i boken "Object thinking" där David West skriver:

Vem vill att någon annan ska kunna gå in och ändra informationen vi har i vår hjärna?

Själv använder jag mig av automatiska properties, men jag tror många kommer av lathet använda dom på fel sätt..

/Fredrik Normén
"


Som fortsättning så kan jag tycka att det är bra att möjligheten finns.
Vill man hindra att folk skriver dålig kod så, så får man lösa det med FxCop eller bra policys eller motsvarande. Intressant att termen då lat används som = oinformerade/dåliga i context för att inte ta med validering men som positivt när det är från orginalartikeln...

En kodare som inte skriver validering i get/set för automatiska properties gör det antagligen inte heller (tror jag) om man får skriva dem manuellt.

Som förslag på vad använda för att slippa koda in affärsvalideringen vad gäller egenskaper/properties så finns det ju te x iom MS Enterprise Library möjlighet iom Validation Framework att lägga på valideringen ovanpå lite likt AOP, genom att injicera valideringen.
Se mer på <ulr:http://msdn.microsoft.com/sv-se/library/cc511802(en-us).aspx>


Eftersom så många tar upp att begränsa är vägen att gå för undvika att folk inte kodar "dåligt" så bara måste jag isf. kontra med att isåfall:
* Borde absolut option strict vara påslaget direkt i VS för vb.net applikationer (som krav för att få gamla vb.Are at förstå att det alls finns då man själv isf. måste slå av det, och kanske då få/ta reda på varför det alls är på det viset.)

* standarden att databinda med Eval borde absolut inte vara med i grundexempel för databindning. Använd ist. explicit databinding Mer info om Eval på ”Minimize Calls to DataBinder.Eval" på http://msdn.microsoft.com/en-us/library/ms998549.aspx#scalenetchapt06_topic13

* Att alla kontroller har viewstate default OFF istället för On som det är nu i asp.net, särskilt då den ofta inte behövs. Det är VÄLDIGT lätt att missa av allt från nybörjare till "experter" att slå av denna potentiella prestanda "hog" (av lathet eller bristande rutin, eller likn.)
Mer info om viewstate på http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx


Om vi ska löpa linan ut som ett tankeexperiment så varför inte tvinga alla att använda MDI-Specialister, använda fokusgrupper och användarscenarion i samråd med potentiella användare?

Tvinga alla som gör webbsidor att validera sina webbsidor mot antingen html 4.01 strict eller xhtml 1.0 strict eller xhtml 1.1 (vi vill ju inte att de är lata och skriver in stilinformation i det semantiska datat, eller trycker in en massa hårda radbryningar <br> för att få ett visst avstånd mellan olika delar i en löpande text?)
För att bryta mot doctypen är ju eg. att bryta mot datakontraktet om man ser doctypen som ett kontrakt, och inte som en "fix" att försöka få de kontraktsbrytande webbläsarna att rendera det uppmärkta datat som utvecklarna tänkt.
Listan kan göras hur lång som helst.


En renodlad kodare kanske inte behöver vara GUI-specialist, men det vore bra om denna kände till att det finns folk som faktiskt kan den biten bättre.
En webbutvecklare kanske kan grunderna i html, men bör veta att man kanske inte är den med mest kunskap om hur skriva html/css.
En generell utvecklare är kanske inte den som kan "allt" om hur skriva SQL/T-sql eller optimera databaser.
Hur många av alla utvecklare har inte arbetat med delar ovan eller andra delar som man kanske inte är eg. bäst lämpad att göra?
Är det av då av lathet, gnidenhet, kompetensbrist eller vad beror det på?


Vad jag vill komma fram till är att i slutändan är det kanske läromedel, lärare, tutorialskrivare, evangelister mm som får se till att de som lär sig koda gör det så att de är medvetna om var de kan få hjälp om "hur göra" för olika delar i utvecklandet av den totala produkten.
Pattern and Practices teamet gör ju en del guider bl a.
Mer info om dem på http://msdn.microsoft.com/en-us/practices/default.aspx

<b>För att bryta mot doctypen är ju eg. att bryta mot datakontraktet om man ser doctypen som ett kontrakt, och inte som en "fix" att försöka få de kontraktsbrytande webbläsarna att rendera det uppmärkta datat som utvecklarna tänkt.</b>

Bra uttryckt! DOCTYPE är ett "kontrakt", inte information om hur sidan skall renderas.

"En kodare som inte skriver validering i get/set för automatiska properties gör det antagligen inte heller (tror jag) om man får skriva dem manuellt. "

Problemet här är oftast dum lathet eller oerfarenheter om vilka risker som finns eller vad valideringa faktiskt kan ge för nytta. Jag tycker det är dumt av bl a C# teamet att faktiskt tillåta automatic properties av just det skälet. Vi kan ju lika gärna använda publika fält. Properties är ändå bara anrop till privata fält och struntar man i hur man sätter och hämtar värdena så ser jag bara properties som något rätt onödigt faktiskt. Att behöva ange set och get kan i alla fall öka chansen att man tänker till lite än när man inte tvingas skriva dem. Dvs det är lätt att glömma av varför och till vilken nytta man gör saker om man helt plötsligt inte behöver...

Jag har stött på många som vägrar lyssna på nya idéer och principer med argumentet. Min lärare sa att man inte skulle göra så o jag lyssnar med på han än dig. Huum... Vet ju inte vad de haft för lärare men hoppas bara de var trötta o hade en dålig dag när de säger dessa kommentarer :)

Idag är det så lätt för vem som att koda och få saker att fungera men känner inte till allt det där bakom koden som man egentligen bör känna till. Det är väldigt många som säger; varför skall jag bry mig? Min kod gör det jag säger till den att göra räcker inte det?

Detta är ett stort problem och det är bla därför vi är några som bloggar, skriver krönikor, anordnar träffar via ex SweNug, Alt .Net etc för att försöka få ut de budskap som inte annars alltid kommer ut.
SweNug i GBGs existens har börjat komma in till it-universiteten. Vilket är kul för det är fler elever nu i SweNug än det var för två årsedan. Och jag hoppas skolorna inser hur en sådan idell organisation faktiskt kan kompletera eleverna då de inte hinner lära sig allt i skolan...

Tyvärr...

Mvh Johan

" Att behöva ange set och get kan i alla fall öka chansen att man tänker till lite än när man inte tvingas skriva dem."

, och det är precis Det jag själv inte tror. D v s människor som skriver en get/set manuellt kontra ngn som skriver dem automatiskt. Det jag sett otaliga exempel på är människor som skriver motsvarigheterna automatiska get/set utan validering ändå, och det utan att för en millisekund fundera över varför de behöver göra så. Jag såg att du längre in i kommentaren skriver att det ökar chansen, jag tror att om det i läromedel, exempel mm visas i samband med validering och förklaring till varför kommer att bidra mer till att man blir varse konceptet.

I "BLL-lösningar" har har det ju funnits validering av datat där ( de de klasserna) istället för på objektet och därmed kanske inte kommit ut i gamla exempel?
Beroende på om man då utvecklat med inkapslingstänk (objektet ska validera sig självt) eller objekt som datastrukturer för att förmedla data har då valideringen skett på olika ställen.
Jag säger absolut inte att det ena är bättre än det andra, bara reflekterar över varför tidigare exempel kanske inte använt validering i get/set

"Properties är ändå bara anrop till privata fält och struntar man i hur man sätter och hämtar värdena så ser jag bara properties som något rätt onödigt faktiskt."
Jag håller med dig på denna punkten. OM man nu reflekterar som nybörjare över varför man behöver dem när man databinder och där inte kan använda fält så kanske man senare kommer in på inkapsling m.m.
Vissa egenskaper kanske inte har några valideringskrav, en del behöver det men kanske lägger på dem i efterhand (se tidigare om validation framework; detta ger intressanta aspekter p att använda samma strukturer på olika plattformar och kunna ta med hela regelverket som konfigurationsfiler istället)

"Jag har stött på många som vägrar lyssna på nya idéer och principer med argumentet. Min lärare sa att man inte skulle göra så o jag lyssnar med på han än dig. Huum... Vet ju inte vad de haft för lärare men hoppas bara de var trötta o hade en dålig dag när de säger dessa kommentarer :)
"
Det lät tråkigt :(
Vissa människor är helt enkelt slutna och eller inte mogna just då att ta till sig de för dem nya delarna.
Bra argument och stegvis (små steg) fram till slutmålet underlättar, men på vissa hjälper knappt något.



Om du verkligen vill begränsa en del utvecklare för att det kan leda till dåliga kodvanor för andra utvecklare varför kommenterar då du inte Viewstate exemplet?
Det om något ser jag själv som en del som man missar att fråga sig om man verkligen behöver eller inte, där det i mitt tycke vore bättre om man själv fick slå på den, än att den per automatik är påslagen. Jag har som ett exempel kommenterat en av de starterkits som finns på www.asp.net/learn
där viewtaten låg på 2MB!!


Slutligen så tycker jag verkligen inte att förhindra är rätt väg att gå, informera och underlätta är bättre.
Jag har lyssnat på ditt argument, men håller inte med dig på denna punk om aut. properties, med motivering enligt (informera, underlätta att göra bra lösningar).
Där kan dock verkligen samarbete (skola med SweNug) som du säger vara en bra lösning för att få in coding practices på utbildningar( i syfte att informera och m h a kodeexemepl underlätta ;) ).
// Mvh Jon

Just angående automatiska properties så tycker jag dom både är onda och goda.

Goda på det vis att det går jättefort att göra dom.

Onda för att det inte blir konsekvent. I de fall jag har validering så måste jag ju ha en privat medlem och jag gillar inte att blanda då tycker jag nog det är bättre att man gör samma med alla.

Sedan har vi lathetsfaktorn är det en autogetset metod kanske någon drar sig för att implemmentera kontrollen för att de inte orkar lyfta ut innehållet till en privat variabel osv.
Som nämnts tidigare vad blir skillnaden mellan en publik medlemsvariabel och en property i detta fallet?


Jag håller också med påståenda med att man skall försöka låsa vägarna att gå för andra utvecklare. Ju mer man öppnar upp vägar att gå med sin kod desto mindre förändringsbar blir den enligt mitt sätt att se på det.

Det är som när man bygger ramverk, man skall exposa så lite som möjligt för när det väl har levererats kan du aldrig ta tillbaka det.

skillnaden blir att OM du använder en property istället för ett fält så kan man
1) databinda instanser från klassen
2) lägga på validering i efterhand till klassen, utan att bryta kontraktet att det är en egenskap
3) lägga på t ex m h a validation framework validering antingen som
a) decorator ( attribut till egenskaperna)
b) m h a injecering och denna injecering kräver egenskaper att "attach:a" sig till för när de anropas, dessa metodanrop interceptas och validering kan då ske innan värdena faktiskt fysiskt sätts.

Här kommer då informationsvis
att det tex kan se se ut så här som dekoreringsexempel

[RequiredStringRule]
        [RequiredStringRule(InitialValue = "aaa", IgnoreCase = true, TrimWhiteSpace = false)]
        [LengthStringRule(50)]
        public string FirstName {
            get; set;
        }

        
        /* valideringen interceptas och sköts av annan klass via konfigurering istället, dvs koden behöver t ex inte kompileras om! */
        public string FirstName {
            get; set;
        }

Jon:
Det finns olika sorters valideringar. Alla vill heller inte använda valideringsramverket. Jag använder det inte. Jag ser hellre att man kastar in BDC i C# så som Spec# har istället. Det är ett trevligt ramverk men kräver en motor och jag som kodare är en defensive kodare "Defensive programming" jag vill inte blanda in massa andra ramverk för dem kan man gå förbi. jag vill tvinga användaren av min kod att förstå varför de gör fel, varför just den proppen inte kan ha siffran 3 eller order "Hej".

Ang databindning så handlar allt om hur MS löst detta. Det finns inga problem alls att köra med fält om stöd finns för det. Sen kanske man inte vill binda alla proppar heller och då kan man använda proppar på det man vill binda för göra koden ännu mer tydlig, dessa skall gå att binda o dessa skall inte gå att binda etc etc...

Du missar en annan tydlig princip. YAGNI. Varför skall jag förbereda en klass för ex AOP stöd rörande proppar om jag inte nyttjar AOP? Varför inte när jag ev måste nyttja AOP då refactorera just de fält som jag vill ha AOP stöd på? Istället för att ge alla fält stödet?

OBS! Jag kör inte med publika fält i min kod. Jag kör proppar och försöker så gott det går styra dem efter DbC i kod utan ramverk om jag kan av det skäl jag nämde innan, ramverk (Attribut) kan man gå förbi om man som kodare vill och min kod skall man inte kunna gå runt för då använder de den helt fel.

Johan:
"Det finns olika sorters valideringar. "
Ja DET vet jag redan ;)

"Alla vill heller inte använda valideringsramverket."
Aldrig påstått heller.
Eftersom du svarar på mitt svar till niclas så misstänker jag att du baserar dig på att jag skrev att "OM man använder Properties så kan man"? (notera särskilt ordet KAN, inte måste)

"jag vill inte blanda in massa andra ramverk för dem kan man gå förbi."
Man kan gå förbi get/set med för att påverka ett fält så för mig är det inte ett giltigt argument.

"jag vill tvinga användaren av min kod att förstå varför de gör fel, varför just den proppen inte kan ha siffran 3 eller order "Hej". "
Exakt hur menar du att sätta validering inne i get/set till skillnad från andra alternativ skulle bidra till ökad förståelse?
Använder man som ett ex ett färdigt klassbibliotek så är det jag kommer på i s f att man m h a dissamblering direkt SER valideringen inne i get/set:en.
Detta förfarande strider dock mot encapsulation principen att för att använda ett API behöver du bara känna till dess Interface (även om god dokumentation ytterligare underlättar).
Vad jag förstår så kan man om jag fortsätter klassbiblioteksexemplet kasta helt egna exceptions, eller befintliga som tex ArgumentException oavsett om man skulle använda validation framework, eller validering direkt i get/set; dokumentation om dessa exceptions i kod som attribut på metoder/egenskaper kan man göra oavsett. Utvecklar man mot klasbiblioteket och får tillbaka exception när man försökt sätta/läsa värde från egenskap så är det ju det felet man tittar på. Varti skulle skillnaden ligga om det var direkt i /get/set:en eller från validering m h a tex validation framework felet triggades?
Så förklara gärna för jag hängde inte med på resonemanget, och blir nyfiken på att ev. lära mig något nytt.


"
Ang databindning så handlar allt om hur MS löst detta."
Ja det vet jag, jag tog upp det som ett av alla skäl till niklas om skillnaderna mellan att använda publika fält och egenskaper. Jag ska ytterligare förklara för Nicklas ( och andra som läser tråden) om ytterligare skillnader mellan properties och publika fält i ett helt eget svar på hans fråga.
Databindningsdelen mot kontroller med properties finns t e x beskrivet som "They have disqualified public fields as a viable way to read and write data to an object in their data binding solutions."
på http://www.lowendahl.net/showShout.aspx?id=155 som jag mistänker att du läst (du använder likn. argument och termen YAGNI)


"Du missar en annan tydlig princip. YAGNI. Varför skall jag förbereda en klass för ex AOP stöd rörande proppar om jag inte nyttjar AOP?"
Först ett förtydligande för andra som läser tråden:YAGNI = 'You Ain't Gonna Need It'
Mer info på http://en.wikipedia.org/wiki/YAGNI
Jag har inte påstått att du SKA göra det. Jag har nämt validation framework som ett ALTERNATIVT sätt att jobba med validering av objektvärden. Jag har innan även nämt tidigare lösningar såsom BLL som tagit hand om valideringen.
Jag har nämt det som ETT ex. på när det kan vara trevligt att använda aut. properties.
Valet att när/om använda validation framework är upp till utvecklingsgruppen/arkitekten.
Vill man använda den lösningen så vill man (baserat på deras projekts förutsättningar) och då finns valet (inte kravet)



Slutligen
Jag känner att huvudtråden, ang. att begränsa kodare eller inte kommit på glid.
Rubriken på tråden är "Hindra "lata" utvecklare?"
Hur du väljer att göra när du kodar är upp till dig, hur andra utvecklare gör är upp till dem.

Som exempel finns då validation framework som det troligtvis finns projekt som använder?
De har sina helt egna motiveringar till varför, samt prioriteringar/värderingar om det är bra eller inte baserat på t e x argument om att man skulle kunna kringå attribut ( beroende på hur man lagt upp koden). OBS Detta är endast 1 exempel på när de kanske skulle gilla att använda aut. properties.

Om jag sammanför det så skulle i s f ditt tycke om att man inte ska använda validation framework då användare av kod (utvecklare) ev. kan gå runt valideringen för att det MÅSTE finnas validering på alla egenskaper (även om vissa egenskaper ev. inte behöver validering, eller inte kommit på att det behövs) då förhindra ALLA från att använda aut. properties genom att de helst inte borde finnas.

Jag slutar med: http://weblogs.asp.net/scottgu/archive/2007/03/08/new-c-orcas-language-features-automatic-properties-object-initializers-and-collection-initializers.aspx
Där skriver Scott Guthrie:
"When the C# "Orcas" compiler encounters an empty get/set property implementation like above, it will now automatically generate a private field for you within your class, and implement a public getter and setter property implementation to it. The benefit of this is that from a type-contract perspective, the class looks exactly like it did with our first (more verbose) implementation above. This means that -- unlike public fields -- I can in the future add validation logic within my property setter implementation without having to change any external component that references my class. "


// Jag ser fram emot ditt svar och är medveten om att jag kanske kan lära mig något på kuppen, men som det är nu ser jag det inte som att aut. properties är av ondo.

Hej igen Niclas.
Tänkte fylla på med lite mer information om skillnaderna mellan publika properties och publika fält

Från http://pageofwords.com/blog/2008/10/25/CTipAutomaticPropertiesTurnFieldIntoAProperty.aspx

"Versioning
If you expose a public field to callers, changing the name or data type of that
field breaks the contract your class has with it's callers, and they will all need
to be updated.
With a property, you can change the internals of your class, and where it stores the
data, without affecting the caller of your property -- as long as the property has
the same name, type and accessibility, they won't know anything has changed.

This helps with versioning your class, as changes to your class won't affect the
rest of your program."


Lite mer av samma vara:
http://weblogs.asp.net/scottgu/archive/2007/03/08/new-c-orcas-language-features-automatic-properties-object-initializers-and-collection-initializers.aspx
" This means that -- unlike public fields -- I can in the future add validation
logic within my property setter implementation without having to change any external
component that references my class. "


Några huvudpunkter om skillnader, besök länken och läs gärna resten/matrialet under varje rubrik
http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx
You lose binary compatibility
You lose source compatibility
You lose reflection compatibility
"

Redigerat utdrag från
Utdrag från http://stackoverflow.com/questions/205691/new-automatic-properties-in-c-30-whats-the-benefit

Whats the benefit of:
public string User {get; set;}
over
public string User;

Since you can't access the private member in the first case, how is it any different
that just making your property public?


The second example is making the field public, not a property (your question). This
provides a simple way of making simple properties. Properties should be your
default, not public fields; the list of reasons is endless, but starts with:
* encapsulation
* ability to add notification
* encapsulation
* ability to do validation
* encapsulation
* data binding
* encapsulation
* security checking

There can be a number of things that you must do when User value changes. Things
that you don't know in advance or are not present at the time you design your
classes. For example one day you realize that user value should be at least 5
characters long. If you have and property it simple to implement. If you have a
public field you must change that to property and recompile all dependent code.

In essence I think it pays to explicitly separate public/API part of the our types
and the private implementation details.
Did someone mentioned encapsulation ? ;)


// Hoppas det hjälper dig/andra att få en inblick i några skillnader =)

Ja du verkar ha gjort en hel del research inom ämnet :).

Jag kanske var lite otydlig när jag skrev det jag skrev :). Självklart känner jag till att man kan lägga attribut på properties för att med ett ramverk injektera felkontroller, samt att man i framtiden kan ändra namn på de gömda fälten som visserligen inte finns om du använder en autoproperty (finns ju MSIL koden men inte för dig i utveklingsmiljön).

Dom fördelarna som skrivs om properties när det gäller namnbyte gäller ju faktiskt samma här.
Samma sak som du inte kan byta namn på en publik variabel så kan du ju inte heller byta namn på en publik property.

När jag skrev mitt filosofiska fråga, vad blir då skillnaden?

Då menade jag inte sådana saker som namnbyten eller ramverk som injekterar metodik osv, vilket jag kanske borde noterat.

detta påstående var bara en liten del av mitt inlägg så jag tycker det är lite tråkigt att mina andra synpunkter inte spindes vidare på.

Som t.ex.

"Jag håller också med påståenda med att man skall försöka låsa vägarna att gå för andra utvecklare. Ju mer man öppnar upp vägar att gå med sin kod desto mindre förändringsbar blir den enligt mitt sätt att se på det.

Det är som när man bygger ramverk, man skall exposa så lite som möjligt för när det väl har levererats kan du aldrig ta tillbaka det."

Jon:
hehe... man märker verkligen att du är en lärare. ;)

Kan svara kort en gång till, men tror inte jag kommer lyckas bättre denna gång heller.

Jag menar på att properties skulle Egentligen vara helt onödiga om man bara använder dem rakt upp o ner utan validering på eller i dem.
Då skulle man lika gärna kunna använda publika fält. Jag säger varken att man skall göra det ena eller det andra. Utan syftar helt och hållet på just hur meningslösa proppar egentligen kan vara... Sen att ramverken ser annorlunda ut som gör att man inte bara kan använda publika fält idag är en annan diskussion...
MS hade om de velat använda publika fält vid bindning. Det är ett väldans liv ang detta på Java sidan oxå som inte ens har proppar. Något jag vet att C# teamet pratade en del om i början. Och även där Java folk funderat på om de skall ha proppar eller ej... Nu är vi låste till proppar pga bindning m.m.
Så missförstå mig inte...

Om du tittat på DBC (Design by Contract) och Defensive prorggraming så kommer du få större förståelse rörande mina argument om validering inne i Set än ha dem utanpå.

DbC handlar om ett kontrakt mot dig själv och andra. Ex har du en klass klocka med proppen Timmar så skall du helst koda så man inte kan sätta andra värden än ex 0-24 i den. Sätter man fel kommer ett exception kastas till utveckalren som talar om att man använder den fel.
Att koda detta med attribut kräver att man måste alltid gå via någon slags motor av nått slag som slår upp valideringen åt dig. Risken finns att man ignorerar detta ramverk om man inte är den strukturerade utvecklaren och på så vis öppnar upp stora risker till buggar. Jag menar inte att folk kodar så men jag menar på att risken finns. Så jag föredrar alltså DBC i koden före attribut-ramverk för samma sak.

Fler fördelar som DbC har är att du hjälper andra att förstå när de använder din kod fel. Detta med precondistion, postconditions o variants.
Du skyddar helt enkelt din klass från att användas felaktigt. tar vi ett valideringsramverk så skyddar du dig bara mot detta så länge man faktiskt går via ramverket men inget säger att man måste. Men i om DBC kommer du inte undan och kan då ine göra massa lata workarroundas för du inte orka med nogranheten... Etc..:
Precis som VB folk är lata o orkar inte med typsäkerheten o stänger av options...

Mvh Johan

"Kan svara kort en gång till, men tror inte jag kommer lyckas bättre denna gång heller. "
Personligen tycker jag att du denna gången lyckades bättre. Nu är det (i mitt tycke) inte bara till mig, utan alla framtida läsare av tråden som det kan komma till gagn. De kan med få ut något av diskussionen och kanske bilda sig en egen uppfattning.

"Jag menar på att properties skulle Egentligen vara helt onödiga om man bara använder dem rakt upp o ner utan validering på eller i dem. "
På ett sätt kan jag hålla med, men så finns det realiteter som gör att man ändå kanske (ev i onödan) i förtid anpassar sig för det i a f. Dessa har vi redan berört så även jag lämnar det.


Vad gäller DBC
(mer info för andra på tex:
http://en.wikibooks.org/wiki/Computer_programming/Design_by_Contract
http://en.wikipedia.org/wiki/Design_by_contract

Så har jag bara en generell uppfattning om det. Lite beroende på vad för applikation man har och uppdelning kan man se alla metoder till en klass och dess API med in/utdata som ett kontrakt.
Man kan se att om man har indata i form av färdiga strukturer/klasser som kontrakt på indata/utdata.
På det sättet blir API, med tillhörande klasser ett kontrakt för vad du kan göra med dem.
För att mer förstå hur man Kan jobba med pre/postconditions får jag nog lägga lite tid på det.

Förståelse för att det (beroende på hur man lägger upp klasserna/valideringen) Kan spela roll finns från min sida.

Ditt exempel "Ex har du en klass klocka med proppen Timmar så skall du helst koda så man inte kan sätta andra värden än ex 0-24 i den. Sätter man fel kommer ett exception kastas till utveckalren som talar om att man använder den fel."
Detta sätt att utveckla är jag helt med på.
Jag har använt validering både i get/set samt m h a validation framework sedan innan. Jag har använt mig av att kasta exceptions (egna såsom färdiga). Jag kan få samma beteende med båda sätten som du beskrivit i ditt exempel. Hur applikationen ser ut är väldigt beroende på vad man gör med den.

Ett ex (1) från mig blir då att valideringen kan t o m ske intern i samma assembly ( med eller utan validation framework)
för att få samma resultat.
Ett annat ex (2) kan bli att utvecklare får modeller med extern valideringsmotor
men eftersom servicen ligger på annan dator så är valideringen för de instanserna som skickats över inte möjliga att kringå och exception dyker liktväl upp oavsett vad utvecklare fipplat med i sin utvecklingdel.


"Så jag föredrar alltså DBC i koden före attribut-ramverk för samma sak. "
Uppfattat, jag förstår även dina argument till att du gör det.

"Fler fördelar som DbC har är att du hjälper andra att förstå när de använder din kod fel. Detta med precondistion, postconditions o variants. "
Detta förstår jag tyvär inte, men kan vid tillfälle ta reda på. Alltid lär man sig nytt :)

"Du skyddar helt enkelt din klass från att användas felaktigt. tar vi ett valideringsramverk så skyddar du dig bara mot detta så länge man faktiskt går via ramverket men inget säger att man måste."
Jag tror att mitt ex 1 belyser hur man kan komma ifrån det. Antagligen har det att göra med vilken applikationstyp man har?


"Precis som VB folk är lata o orkar inte med typsäkerheten o stänger av options... "
Detta får du helt själv stå för.
VB som i VB 6 eller VB.net kan man ju alltid undra?
Vad gäller att stänga av Option Strict så om du syftar till vad jag skrev innan? om andra delar som man kunde fokusera på att begränsa/ändra så är Option Strict (observera) Avslaget per default; vilket leder till att många som kommer från vb och går till vb.net aldrig ens vet om att de Kan slå PÅ option strict.

De är alltså inte lata i att det är avstängt Däremot kan jag hålla med om att om de aktivt slår av det och vet om vad det innebär antagligen gör det av lathet.


Tack för att du svarade på vad du menade mer med dbc i relation/kontext till validering av objekt.
Det blev kände jag en subdiskusison, för om man borde/inte borde begränsa utvecklare generellt eller inte, och specifikt om man borde begränsa aut. properties.

Vad jag vill säga med titel på detta svar "DBC klargjort, förståelse för din argumentering. Men grundläggande premis kvarstår."
är att jag upplever det som jag förstått hur du tänker, din argumentering till dbc på validering och hur det Kan se ut. Att det i mitt tycke är beroende på vad man har för applikationstyp samt arkitektur.

Jag tycker dock fortfarande att kopplat till om det är skäl nog för att begränsa att utvecklare Har möjligheten att använda aut. properties eller inte;
inte är skäl att ta bort aut. properties.

Jag värderar möjligheten att använda dem större än att oinformerade utvecklare kanske skulle kunna göra fel (det gör de i a f).
Alltså hellre informera än begränsa.

// Mvh Jon

"samt att man i framtiden kan ändra namn på de gömda fälten som visserligen inte finns om du använder en autoproperty (finns ju MSIL koden men inte för dig i utveklingsmiljön)."
Jag tror du fokuserar på fel sak. Du kan med en aut. property ändra den interna logiken ( typ validering)
genom att
a) använda validering
1) tex validation framework
2) validering i get/set
för att i efterhand lägga på validering (likt det Scott Guhtrie skrev i mitt förra svar) för hanteringen av egenskapen.
b) lägga till notifiering
c) säkerhetskontroller

Om du gör det med validering i get/set får du refactorera egenskapen och ta bort den automatiska propertyn, själv ansvara för ett ev. motsvarande privat fält... MEN
du har utåt sett inte gjort något med det exponerade gränssnittet. Vad menar jag? Du har inte ändrat kontraktet för klassen. Den har fortfarande en egenskap med samma namn.


"Sedan har vi lathetsfaktorn är det en autogetset metod kanske någon drar sig för att implemmentera kontrollen för att de inte orkar lyfta ut innehållet till en privat variabel osv.
Som nämnts tidigare vad blir skillnaden mellan en publik medlemsvariabel och en property i detta fallet?"
Förstår jag dig rätt om jag skriver om det du skriver ovan som,
vad är skillnaden avseende ett publikt fält och en egenskap om ändå ingen validering sker?
"Filosofiska" skillnaden mellan att man kan ändra ett datavärde är eg eg ingen.

De reella skillnaderna vad gäller att man ändrat gränssnitt mot omvärlden för klassen, samt det jag länkade till om innan såsom skillnader för databindning,

Tex
"With a property, you can change the internals of your class, and where it stores the
data, without affecting the caller of your property -- as long as the property has
the same name, type and accessibility, they won't know anything has changed. "
Så missförstog du nog den arikelförfattaren. Jag tolkar det som att denna menar att man kan ändra de INTERNA delarna i klassen (private delar.. som i tex privata fält) så länge som inte publika delar ändrar namn.

Övriga reella skillnader ( inte filosofiska) är som jag skrev:
You lose binary compatibility
You lose source compatibility
You lose reflection compatibility

samt:
ability to add notification
* encapsulation
* ability to do validation
* encapsulation
* data binding
* encapsulation
* security checking

Där ability to add och to add betyder ~= att man KAN i framtiden om man vill lägga på de delarna.

Jag är inte motståndare till auto-proppar... :)

"Fler fördelar som DbC har är att du hjälper andra att förstå när de använder din kod fel. Detta med precondistion, postconditions o variants. "
Detta förstår jag tyvär inte, men kan vid tillfälle ta reda på. Alltid lär man sig nytt :) "

Skall se om jag jag förtydliga detta lite.
Jag strävar eller försöker sträva efter att ha kod som andra förstår lika så att jag själv skall förstå min kod senare i framtiden. Det finns väldigt många ??? när man sitter med andras kod, mkt för att den inte talar om vad man egentligen gör för fel med den.

Man brukar säga så här. Skriv din kod, ge den till en polare förstår han inte hur han skall använda den, svara inte på hur den skall användas, du har troligen otydlig kod. Gör om den. Förstår inte din polare koden då heller, gör om tills han förstår. Nu funkar det inte alltid så här tyvärr men ett tankesätt som man kan ha. Hur tolkar andra min kod? hur skall jag få dem att förstå den utan att de skall komma springande och kräva att jag förklarar vad den gör? Eller minst att de måste läsa koden för att förstå hur de använder den?

Vi kan ta klockan igen. Om man inte kör med kontrakt så skulle säkerligen en hel del skicka in lite konstiga tal in i hours proppen. Kanske 80 eller 90 o så orsakas en bugg någon annanstans i ens applikation pga att fel värde fick komma genom någon annan stans. Jag vill ju inte att detta skall hända om jag då kör med BdC kommer jag lära andra att inte skicka in fel värde för de kan inte...
På så vis lär sig andra hur de skall använda min kod. De kan ex inte skicka in null av class A eller ropa på medotd B utan att jag ger ett fel som säger du måste sätta proppen C till nått innan etc... (Så skall man helst inte koda, men vill bara beskriva ett exempel).

Så Precondition är typ det man gör innan ens huvudkod. Pga att C# inte har DBC så blir det mer eller mindre att kolla sina iputs så de uppfyller kontraktet. Sen kör man sin kod. Sen kör man postcondition dvs en sista validering för att försäkra att nes huvud kod verkligen gjorde sitt jobb.
Variant kontroller kan man oxå göra det är mer att verifiera hela klassens tillstånd så inte andra klasser ex returnerat fel värde tillbaka... Ex klockan igen. Kanske man har en metod som hämtar värde från en DB man sätter kanske sin privata variabel via anrop mot denna andra klass:

_hour = andraKlasse.HämtaTimmar();

här kan HämtaTimmar mkt väl ge tillbaka 80 eller ett ogiltigt värde. Genom att ha en variant kontroll så kollar man hela klassens tillstånd så de uppfyller kraven.

ja lite DbC skola i kort format...

Mvh Johan

Men du behöver inte skriva milslånga förklaringar om vad en property är bra för. Jag och de flesta andra här vet vad en property är bra för, vad den har för fördelar, vad man kan göra med dom.

Min rad där jag efterfrågade skillnaden mellan en dum get set och fält var att i praktiken är det ingen skillnad tills du som du säger lägger på funktionalitet. Det fattar jag utan några problem. Det känns som att du utgår från att ingen riktigt förstår vad en property är.

Och som jag bad om kan vi inte spinna vidare på mitt andra svar eftersom just det med properties var den minst intressanta delen i mitt inlägg.

Hej Niclas.

Verkar som du besvarade en annan kommentar än från mig till dig
Den kommentaren du besvarat var till Johan N.

Iaf:
Kort svar (skillnad prop/fält) : Klargjort sedan innan :
filosofiskt = ingen
praktiskt = skillnader finns ( beskrivet som du säger flertalet ggr)

Vad gäller antalet som verkligen vet vad properties är samt praktiska skilnader mellan dem så har jag inte någon statistik baserat på medlemmarna'/besökarna på pellesoft. Jag HAR dock sett alarmerande många som ger tecken av att om inte missat helt.. så missat en hel del väsentligheter.


Förlåt om du tog anstöt av övertydligheten. Det var dock inte riktat mot dig som person, utan till alla dem som kanske läste tråden. Dessutom (som vi redan behandlat) feltolkade jag din fråga till att tro att den gälde vilke praktiska skillnader det faktiskt fanns.. där jag enbart försökte vara utförlig.


>"Och som jag bad om kan vi inte spinna vidare på mitt andra svar eftersom just det med properties var den minst intressanta delen i mitt inlägg."
Varför skulle vi inte kunna det?
Om du fortfarande vill diskutera ytterligare delar som du fann intressantare är mitt förslag att du startar en ny tråd om dessa delar, förutsatt att det inte hade med ursprungsdelen i denna tråd :
"Hindra lata utvecklare"
Så kan jag besvara dem.

Hänt mycket här medans jag har varit borta på fartfylda äventyr i USA..

Jag håller med Jon, det är ofta fler än en som vill veta ett svar, så även om den som skriver en fråga vet tex vad en property är och hur man borde använda dom, så vet inte alla det. Så jag tycker det är bra att man är tydlig så andra kan ta fördel av diskutionen.

Jag håller med Uncle Bob (Robert C. Martin) när han säger:

"There is a reason that we keep our variables private. We don't want anyone else depend on them. We want to keep the freedom to change their type or implementation on a whim or an impulse. Why, then, do so many programmers automatically add getters and setters to their objects, exposing their private variables as if they where public?"

Jag skulle vilja att en automatisk property "by default" skapar en ReadOnly property, detta för att köra efter en mycket bra princip "Start creating immutable classes, open it up when you need to".

Jag gillar automatiska properties, men många utvecklare av ren "dumhet" använder dom och bryr sig inte om att göra dom readonly. Genom att skapa dom själva, så kan dom av ren "lathet" strunta i set om de inte behöver dom. Men jag har hört att C# teamet tittar på att göra automatiska properties readonly, för det går inte idag, vi måste då sätta en protection level för att tex dölja set.

En annan fundering är oxå hur mkt måste MS göra för att folk skall koda rätt ;-)

För mig är det exempelvis inga problem att hantera proppar automatik som icke... men det är ju så många som inte kan tyvärr... Men frågan är om MS IDE är lösningen?

Kan inte se vitsen med att MS IDE kör readonly automatic properties när det är en sådan liten justering för att lösa det i ex C# kanske att set är private som default? eller... nja svårt detta...
För tanken är god men inte lika kul den dagen då vi kanske vill ha massa set o get proppar o slippa då ha readonly som default :)

Men i VB blir det ju lite mer jobb att hantera detta för de stackarna.


Ang förtydliga poster:
Jag tycker väl inte det är fel med det, men då bör man vara tydlig för vem man förtydligar dem för.
Citerar man ex en person här och sen skriver en uppsats vad saker gör så kan jag mkt väl förstå att man kan ta det personligt då det mer eller mindre faktiskt riktas till personen spec om posten börjkar med ex:

<namn>:
text

Nu spårar det nästan ur igen (det om förtydliga eller inte)... ;)

Frågar man generellt efter vad är skillnaden mellan a och b?
Så får man nog bereda sig på ett utförligt svar utan att väcka anstöt.
Frågar man specifikt får man specifika svar. Sedan kan ju alltid information förvrängas från sändare till mottagare (när det äller kommunikationsteori), dvs man kan missuppfatta varandra ( som jag gjorde när det gällde de rent "filosofiska" skillnaderna...

Information kan vara både riktad mot en person specifikt och en generell massa, och att då kanske tagga upp informationen som detta är till alla andra och detta är till dig blir då kanske lite klumpig?

Lättast vore då nästan om personen som frågar vad är skillnaden mellan a & b ger som du beskrivit (iom design by contract) preconditions för sin fråga så man vet vad man INTE behöver svara på isf ;)

Rent pragmatiskt som du beskrivit det i Swenugs nedladdningsbara dokumentation på http://www.swenug.com/files/ "En pragmatisk utvecklare kodar i defens för sig själv och för andra!"

Så beskrev jag då defensivt både gentemot Niclas och alla andra då jag omöjligt kan veta om Niclas (eller t.o.m övriga läsares) kompetensnivå på förhand.

Tittade lite på vad ni själva producerat vad gäller dbc och delarna om pre/post-conditions från Swenug's download-sektion.

"Defensive programming & Desing By Contract - Code Camp" på:
http://www.swenug.com/files/


Det finns inget som talar till mig så tydligt som kod ;)
Så jag klistrar in den kod som talade tydligt till mig för andra som kan vara intresserade

namespace Dotway.DbC.Demo
{
    /// <summary>
    /// Kontraktet säger, att timmar måste vara mellan 00-23 då skall användaren av klassen få veta vad han/hon gör fel.
    /// Det är upp till utvecklaren att hjälpa sina andra medarbetare att förstå vad de gör för fel, det är oftast inte de som gör fel, utan du 
    /// som inte förklarar för dem vad de gör för fel, ge inte dem ansvaret att försäkra att din klass fungerar
    /// 
    /// @PostCondition - Kolla så allt är ok, inputparametrar m.m.
    /// @Precondition - Se så go/do/command själva logiken verkligen gjorde det den skulle
    /// @Invariant - kolla klassens tillstånd m.m. för att go/do kan ropa på andra klasser som kan ge fel retur m.m.
    /// </summary>
    public class Clock
    {
        private int _Hour = -0;
        public int Hour
        { get { return (_Hour); } }

        public void SetHour(int hour)
        {
            CheckHourValue(hour); //Require @PostCondition

            _Hour = hour; //Go/Do
            
            if(_Hour != hour)
                throw new ApplicationException("Hour was never set!"); //Ensure @PreCondition

            CheckHourValue(_Hour); //Invaraint
        }

        private void CheckHourValue(int hour)
        {
            if(hour > 23 || hour < 0) 
                throw new ArgumentException("Input parameter hour must be between 00 and 23");
        }
    }
}

Rubriken är satt till generell fråga -> generellt svar så kastar in lite tankar baserat på denna rubrik. Även om det kanske inte ingår här.

Jag förstår detta med att göra förtydligande utan tvekan. Men när är ett förtydligande för mycket och för lite? Jag själv läser forum så här:

Jag säger nått. Någon svarar mig. När någon svara någon annan brukar jag oftast (inte altid) ignorera detta då det inte är svar till mig. Om det då i detta svar till någon annan står en längre beskrivning för att förtydliga för andra vem läser det då? Jag gör det inte för det var riktat till någon annan, om nyfikheten inte tar över så klart o man vill veta vad som skrevs till andra. Men det är i ca 40% av fallen jag kanske läser en post riktad till andra.

Att jag lägger mig i detta och trollar lite i denna tråden med just dessa saker är för att jag kan inte komma på vart man kan ta upp denna diskussion just nu. Kanske under allmänt ? jag är även moderator på vissa kategorier här på pellessoft på så sätt är det ju matnyttigt att veta hur vi vill använda forum.

Jag tycker gränsdragningen är svår och märker att vi har ett problem här oxå.
Vi pratar ju om att förtydliga saker för andra men även för oss själva som terapi ;-) men hur förtydligar vi det så att det vi skriver verkligen blir riktat till rätt person.

Jag lever under den forumsfisofin att man bara ger svar på det som efterfrågas eller de tankar som tas fram. Om någon inte förstår får vi i så fall lägga en post som ställer frågan, kan du förtydliga?.
Detta för att poster faktiskt kan bli ottroligt långa. Vi märker redan nu att det blev missförstånd och vissa personer tog åt sig av förtydligandet. Stämmningen kan ju bli lite negativ tyvärr och som moderator har jag ju lite som uppgift att hoppa in o säga till. Även om jag gör fel ofta ;-)

Men jag vet inte... jag reagerade i alla fall och reagerade på hur andra reagerade/reagerar...

Någon ottrevlig stämmning vill vi ju inte ha...

Kanske skall ta upp denna diskussion i någon annan tråd. Eller under en bit lunch i Gbg?

@Jon
Gillar koden du klistra in.. HAHA känner igen den ;)
I C# 4.0 kommer den dock bli mkt trevligare... Skall bli kul o se hur DbC blir i C# 4 det finns ju lite kod o idéer ute redan nu, men vi vet ju alla att sånt ändras på vägen.

mvh Johan

fattar inte ens c# o vet inte ens vilken fil man ska skriva programmet i i det gamla c++ var det bara en eller flera cpp filer o en o en annan .h fil till o börja med
men kan nån förklara hur ja kan komma igång med c# skulle ja va glad

mvh Anders

@JON

Vet inte vem som skrivit koden och hoppas ingen tar mitt inlägg personligt. Men den är fel..

Pre = "Före"

PreCondition handlar om att validera, i DbC är detta "om jag får detta" och PostCondition är resultetet "då får då detta".

I C# har vi inte stöd för DbC, vi kan iofs använda Validation Blocket från PAG som kan hjälpa oss, men annars får vi själva skriva validering av input i metoder.. Så PreCondition är att säkerställa att vi får rätt data innan vi kan utföra något. PostCondition säkerställer att vi ger tillbaka rätt data..

Spec# har stöd för DbC men är bara ett MS research projekt. C# teamet vill ha in DbC, men vet inte vart de ska spara "dokumenten" (kontrakten). Så i och med CLR 4.0 så kommer vi ev få ett ganska ok DbC stöd. Vi kan tex skriva:

public object M(object arg)
{
Condition.Required(arg => arg != null);
Condition.Ensure(...)
}

Condition metoderna kommer anropas vid compile time och verifiera, samt i runtime.

Jag skrev för några år sedan en blog post om just DbC och hur det kan lösas i C# 2.0 och nämner lite hur det funka i Spec# om du intresset finns (OBS! Gammal post och från mitt gamla blog):

"Defensive programming and Design by Contract on a routine level"
http://fredrik.nsquared2.com/ViewPost.aspx?PostId=245

@bror

Jag som skrivit koden. Troligen jag som la in kommentarerna oxå då det var en snabbdemo kod.
Ser nu oxå att jag satt post och pre på tvärtom ställen. Klart pre skall vara före och post efter :-)

My bad... Nu ser man nyttan med open source ;-) review FTW!!!!

Tack... Skall justera detta. Skumt att ingen reagerat på det innnan, jag själv var blind i demot så såg det inte heller...

Det är lite som vänster och höger... SOm man lätt kan ta fel på i all tänkande hast :/


Mvh Johan

Låt oss utveckla ett nytt operativsystem så vi en gång för alla slipper skiten som Microsoft spyr ut

>Låt os utveckla ett nytt operativsystem så vi en gång för alla slipper skiten som Microsoft spyr ut


Oj... Gör du HTML så gör jag javascript, sen har vi ett jätte bra OS..

> Oj... Gör du HTML så gör jag javascript, sen har vi ett jätte bra OS..

Det är ju precis vad Google gjort. Ett OS byggt på webb :-/

Jag säger flopp :)