7

Possible Duplicate:
Properties vs Methods

I have some vector geometry classes, and there is lots of functionality I don't know whether to implement as (readonly) properties or methods. Examples include:

Vector.Length                   or              Vector.Length()
Vector.Perpendicular            or              Vector.Perpendicular()
Matrix.Determinant              or              Matrix.Determinant()
Matrix.Inverse                  or              Matrix.Inverse()

Should I implement these as methods, or as properties? None of them mutate the object they apply to, so in that respect, they seem suited as properties. On the other hand, they involve calculations (albeit small ones - this is 2D geometry), which is apparently bad for properties.

Is there any rule as to which I should use in this scenario?

Community
  • 1
  • 1
Eric
  • 95,302
  • 53
  • 242
  • 374
  • @Kristopher: These strike me as edge cases: They don't have side effects, but they include calculations. – Eric Jun 10 '11 at 16:45
  • 1
    properties are meant to have calculations, and not just getters and setters. They are there for uniform access so that you may e.g. represent a point in (x,y) coordinates and still provide access to (r,theta) as "properties" without the user noticing it. – Yet Another Geek Jun 10 '11 at 16:49
  • @Yet Another Geek: Good point. That puts `Vector.Length` and `Matrix.Determinant` on the property side. It's the other two I'm unsure of. – Eric Jun 10 '11 at 16:51

4 Answers4

5

Properties are meant for enabling the Uniform Access Principle, and thus properties is the best choice here eventhough you got some calculations. This is because they are things that describe an object more than doing things to an object and do not require parameters for any external calculation.

With right to mutation, getters should not mutate and setters may mutate according to the Command Query Separation Principle.

Yet Another Geek
  • 4,251
  • 1
  • 28
  • 40
4

I would implement Vector.Length and Matrix.Determinant as properties, as they entail very lightweight calculations (2D).

However, Matrix.Inverse and Vector.Perpendicular don't fit, IMHO, as properties because they aren't describing the object. They are returning a new object that happens to comply with some mathematical condition. I'd implement these as Vector.GetPerpendicular() and Matrix.GetInverse()

But of course, this is just personal taste. I'd do it that way but its perfectly fine to implement them all as properties.

InBetween
  • 32,319
  • 3
  • 50
  • 90
  • But the fact that you started the method name with `Get` implies they should be properties! – Eric Jun 10 '11 at 16:48
  • 1
    No at all. It is a usual naming convention in the .NET Framework to name methods that return information as GetInformation. Check the `Type`class for instance. – InBetween Jun 10 '11 at 16:50
  • @Eric: Not completely. Although FxCop does warn about this, users of a property won't expect calling a property would not expect it to have any performance penalties, while it is assumption is easier made for methods. If your `GetXXX()` method is slow, don't change it to a property. – Steven Jun 10 '11 at 16:53
1

Usually people assume that properties are not too expensive to invoke and that they will complete in near constant time. It sounds like you would be fine with a property.

agent-j
  • 27,335
  • 5
  • 52
  • 79
0

People generally expect methods to take some time to execute (and potentially throw) while this is less true for properties.

For instance you are more likely to have a property as a condition in a for loop than you are to see a method there. Methods are somewhat expected to have side-effects while properties are expected to not mutate the object.

As a rule of thumb, if you are comfortable with your properties being executed hundreds of times then they are ok.

If you go with methods, it might help it you call them GetXxx().

Andrei
  • 4,880
  • 23
  • 30
  • As it stands, I'm caching the result of `Matrix.Inverse`, so after the first execution it *is* just a field access. (The classes are immutable) – Eric Jun 10 '11 at 16:52
  • @Eric, what does Perpendicular calculate? Even "Inverse" could be a property, as long as you document is as having overhead on the first call. – Andrei Jun 10 '11 at 16:56
  • The [perpendicular vector](http://mathworld.wolfram.com/PerpendicularVector.html) – Eric Jun 10 '11 at 17:00
  • @Eric: So it returns a new vector. This one might be better suited to be a method. – Andrei Jun 10 '11 at 17:06