När bör man välja metod istället för en egenskap (property)?

Om vi tänker oss att en orderline som har en egenskap för att hämta upp totalpris för en vara. Då tror jag de flesta skulle välja en property likt nedanstående.
public decimal TotalPrice
{
get { return UnitPrice * Quantity; }
}



Om vi däremot börjar få allt mer logik tex i order för att räkna fram totalpris för alla varor. Skulle man välja en egenskap eller en metod för detta? Nedanstående är ett exempel på en egenskap.

public decimal TotalPrice
{
decimal totalPrice = 0;

foreach (OrderLine orderLine in _orderLines)
{
totalPrice += orderLine.TotalPrice;
}

return totalPrice;
}

Jag brukar använda följande kriterier för att skapa en metod:

- Om egenskapen tar betydligt längre tid att utföra en att bara sätta eller returnera ett värde.
t.ex. om funktionen innehåller loopar eller använder något externt system (filsystem, webservice, databas)

- Om egenskapen kan kasta undantag i produktion (gäller främst "get")
Är väl inte helt strikt här men i princip menar jag att man inte skall få FormatException, IndexOutOfRangeException eller InvalidCastException och sånt.
InvalidOperationException är ok

Innebär detta att du skulle gjort TotalPrice i ovanstående exempel till en metod istället för en egenskap? Skulle du kalla metoden för GetTotalPrice eller TotalPrice?

Med mina kriterier skulle det blivit en metod.

Däremot skulle jag nog inte haft en sån metod överhuvudtaget. Jag skulle itererat över raderna när jag behövde summan.

Snart dyker det säkert upp behov för GetTotalWeight, GetTotalVAT etc och då dyker det upp frågor om GetTotalPrice inkluderar frakt, är med eller utan moms, beräknad på beställd eller levererad kvantitet etc.

foreach & delegates/lambda gör det mer tydligt.

Min metod skulle nog heta "GetTotalPriceOnOrderRowsExcludingVatForDeliveredQuantity" :-)

Tja,

Tycker detta är en intressant fråga. Jag skulle nog döpt den till GetTotalPrice() om det är en metod. Att döpa den till TotalPrice är inget direkt verb vilket metoder skall spegla. Det är mer ett Adjektiv och Substantiv är lätt Properties.

Det kan ibland vara svårt att dra gränsen mellan metod och property rörande dess scope.
För mig handlar en Property om att returnera ett publikt tillstånd. Vissa tillstånd kan jag ibland hämta via metod inne i propertyn. Men att beräkna saker är mer eller mindra businesslogik och om det är något som utgör ett verb i din userstory skall du in första hand göra det till en metod. Men är dett ett substantiv eller adjektiv kanske en Prop är på sin plats.

Men det kan finnas risker att faktiskt hantera flera tillstånd i en property. Detta för man vill helst att set och get är släktade. Dvs get total * totalnåttannat hur skulle dess set se ut?

Det finns fall då jag faktiskt gjort privata get- och setfunktioner som någon property kan ropa på, dessa hanterar retur av flera tillstånd, och en get uppdaterar samma tillstånd som min retur hämtar.

Inom Java världen är det delade åsikter om proppar eller ej. Idag kan de inte ha proppar utan bara köära get o setmetoder för de anser det mer rätt i alla fall många av dem, sen har det vart massa diskussioner om att ta in proppar i Java för tillståndshantering m.m. då man ibland vill ha fält publika och det är oftast här proppar fyller sin funktion då du kan hantera ex preconditions och postconditions rörande hur dina tillstånd får sättas eller ej vilket du inte kan med publika fält. Ex valideringar, kolla så att din sättning bara tar emot siffra mellan 0-30...

mvh Johan

Microsoft har satt upp guidlines för detta,
http://msdn.microsoft.com/en-us/library/bzwdh01d(VS.71).aspx

"Use a method when:

* The operation is a conversion, such as Object.ToString.
* The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
* Obtaining a property value using the get accessor would have an observable side effect.
* Calling the member twice in succession produces different results.
* The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
* The member is static but returns a value that can be changed.
* The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the internal array so that the user cannot change internal state. This, coupled with the fact that a user can easily assume it is an indexed property, leads to inefficient code. In the following code example, each call to the Methods property creates a copy of the array. As a result, 2n+1 copies of the array will be created in the following loop. "


Om det finns mer intresse kan jag rekommendera boken Framework Design Guidelines som är framtagen av .NET ramverkets arkitekter där dom skriver hur dom har tänkt och hur dom har tänkt sig att utvecklare skall göra.