C# alleen-lezen berekende eigenschappen, moeten dit methoden zijn?

Ik heb verschillende entiteiten die velden hebben berekend, zoals TotalCost. Op dit moment heb ik ze allemaal als eigenschappen, maar ik vraag me af of ze eigenlijk methoden zouden moeten zijn. Is hier een C#-standaard voor?

public class WorkOrder
{
    public int LaborHours { get; set; }
    public decimal LaborRate { get; set; }
    // Should this be LaborCost()?
    public decimal LaborCost
    {
        get
        {
            return LaborHours * LaborRate;
        }
    }
}

Antwoord 1, autoriteit 100%

Het is oké om berekende eigenschappen te gebruiken in plaats van methoden, zolang de berekening geen merkbare tijd in beslag neemt

Zie Richtlijnen voor het gebruik van onroerend goed

Antwoord 2, autoriteit 25%

Ik denk dat methoden acties op het object moeten uitvoeren, meestal de status van het object wijzigen. Eigenschappen moeten de huidige staat van het object weergeven, zelfs als de eigenschap wordt berekend. Dus je moet je eigendommen IMO behouden.

Antwoord 3, autoriteit 12%

Ik denk dat het allemaal eigenschappen zouden moeten zijn. Zolang het de staat van het object niet verandert, vind ik het prima als eigenschap.

Bovendien, als ik uw klasse gebruik voor gegevensbinding (WPF, enz.), kan ik rechtstreeks aan uw eigendom binden zonder de klasse te wijzigen/uit te breiden.

Antwoord 4, autoriteit 5%

Als ze a) licht van gewicht zijn en b) geen bijwerkingen hebben, zou ik ze Eigenschappen maken.

Lichtgewicht is natuurlijk een beetje vaag, maar de vuistregel is: als ik me ooit zorgen moet maken over het aanroepen van een eigenschap (of het nu in een lus is of ergens anders), zou het mogelijk een methode moeten zijn.

Antwoord 5, autoriteit 2%

Ik zou ze als eigenschappen achterlaten. Maar er is geen “standaard” reden om dingen op de een of andere manier te doen. Als je alleen bent, doe dan wat je het leukst vindt. Als je in een team zit, volg dan de conventies die de rest van je team volgt.

Antwoord 6, autoriteit 2%

Als een eigenschap bijzonder duur is om te berekenen, kan ik deze wijzigen in een GetWhatever()-methode. Dit dient als een hint voor iedereen die mijn klasse gebruikt dat deze waarde veel werk vereist om tot stand te komen, en de aanroeper moet de waarde in de cache opslaan in plaats van de methode meerdere keren aan te roepen.

Triviale berekeningen zijn perfect geschikt binnen eigendommen.

Antwoord 7

Naar mijn mening is het een voorkeur; het is wat je wilt doen. Ik doe eigenschappen in de meeste gevallen, tenzij er logica in het spel is. Bovendien, als u parameters moet doorgeven om de functionaliteit te wijzigen, is er uiteraard een methode van toepassing…

Antwoord 8

Het hangt ervan af, als uw “eigenschappen” mammoeten worden en een hele reeks bedrijfslogica vereisen, zouden het geen eigenschappen moeten zijn, maar er zou een methode moeten zijn.
Het voorbeeld dat je hebt gepost ziet er goed uit om een ​​eigendom te zijn. Geen standaardmanier om het te doen, volg je onderbuikgevoel; als het lijkt alsof het veel moet doen, heb je waarschijnlijk een methode nodig.

Antwoord 9

Het is sowieso grotendeels gewoon syntactische suiker, dus wil je conventie in je team, of wat je liever hebt, zolang het alleen informatie over het object retourneert en het niet verandert of interactie heeft met andere objecten.

Antwoord 10

MSDN geeft informatie over deze hier

Ontwerpers van klassenbibliotheken moeten vaak
beslissen tussen het implementeren van een klasse
member als een eigenschap of een methode. In
algemeen, methoden vertegenwoordigen acties en
eigenschappen vertegenwoordigen gegevens.

Welke denk je dat het is? Een actie berekenen/getLaborCost of data?

WorkOrder workOrder = new WorkOrder();
workOrder.LaborHours = 8;
workOrder.LaborRate = 20;
decimal cost = workOrder.LaborCost; // This is OK here

maar als je dit ook voor hetzelfde object gaat doen:

worOrder.LaborHours = 18;
decimal newCost = workOrder.LaborCost 

Dit kan geen eigenschap zijn. Het zou veel beter zijn om een methode te zijn.

Antwoord 11

Soms moet je ook nadenken over wat je aan het modelleren bent… Op sommige domeinen zijn de berekende waarden vaak of worden ze verwacht een attribuut van het model te zijn — een eigenschap. Als dit het geval was, schrijf het dan op als een eigenschap, ook al is de berekening helemaal niet triviaal of een beetje duur om te berekenen. Documenteer het gewoon in uw API of implementeer een caching-mechanisme om herberekening voor deze eigenschap te minimaliseren.