Yes, they certainly can - there are plenty of examples in the standard API (e.g. Delegate.GetInvocationList).
However, generally it's worth considering whether you actually want a property when you create a GetFoo method.
Yes, they certainly can - there are plenty of examples in the standard API (e.g. Delegate.GetInvocationList).
However, generally it's worth considering whether you actually want a property when you create a GetFoo method.
You can do it, yes, but it is often a strong indication that you should really be creating a property (especially if your method has no parameters).
From the Framework Design Guidelines:
DO NOT have properties that match the name of "Get methods" as in the following example:
public string TextWriter { get {...} set {...}}
public string GetTextWriter(int value) {...}
Absolutely you can use Get in the method name. Personally I use it to make this distinction:
Not called Get:
public string GetSomeString()
{
return _someMemberVariable;
}
Edit: It seems I wasn't clear here, I meant to show that properties with Get in the name are misleading if they do no processing.
The word Get in a method name implies effort required.
public string GetSomeString()
{
//Some code that does processing or includes logic.
}
I believe this is mentioned in Clean Code as a good practice (to make clear that it's not simply handing back a value).
It is perfectly legal (it is even legal to write methods of the form "get_Foo" which would collide with the compiler synthesized get method if you were to declare a property Foo with a getter).
As to Whether it is a good thing:
The above points are subjective but the reason that hard rules like 'never' 'always' can be a bad idea is that the balancing of multiple subjective and competing factors is part of what being a good developer is all about.
It is quite natural to use Get as the begin of method name in my opinion.
If your Get-method accepts parameters, it's absolutely OK to name it accordingly.
If it doesn't accepts parameters, rename it to SearchResults { get; }
And it's much-much better then use parametric properties like in VB.NET:
ReadOnly Property Foo(ByVal i As Integer, ByVal j As Integer) As String
Get
Return ""
End Get
End Property
In fact, in IL it will be method GetFoo(int, int)
but VB.NET is wonderful language!
Yes, I'd indeed use GetXyz
if the method has some side effects, is slow to execute or requires arguments (all cases where you definitely should not use an Xyz
property).
Personally, I mix and match GetXyz
and FindXyz
in cases where returning null
might not be the right thing to do for a get. A get could allocate a new object if it does not find what it is looking for, whereas a find would return null
, for instance.
I use a technique with similarities to some of the above examples - my criteria is that if the property/method is exposing data that already is held in the class, use a property. If we are triggering some kind of action to go obtain the requested value, say from a database, or some other source not already stored inside the class, use a Get.
Oversimplified, properties are nouns and methods are verbs.