I have an interface in c# that helps retrieving of data from a custom archive on server. The interface looks like this:
public interface IRetrieveData
{
bool OkToRetrieve(SomeData data); // Method in question...
bool RetrieveToLocal(SomeData data);
}
This interface is implemented by the clients that retrieve the data to the local database. There are different flavors of clients that have access to each others data. So, when the processing component calls IRetrieveData.OkToRetrieve right before actual retrieve, the call goes to the client code where the decision is made on whether the data should be retrieved or not. At this point the client can return false and that piece of data is skipped or return true and the processing component calls RetrieveToLocal and send the data to the client which then processes it.
Where I am getting confused is whether to rename the method "OkToRetrieve" to just "Retrieve" or "CanRetrieve" or leave it as OkToRetrieve.
Does anyone have any suggestion?
if you are doing more checks and isRetrievable() isn't appropriate you could use:
Methods mean action. Therefore, I prefer method names to start with a verb. How about?
In this specific case, I'd probably name it:
Because it more clearly demonstrates what will happen once this returns
true
.How about using the prefix 'should'?
Depends on your use case. I like to prefix them with words such as 'is', 'does' or 'Can':
IsSomePropertySoAndSo
,DoesNounSupportFeature
and as your exampleCanVerb
CanRetrieve sounds fine to me. I've seen the Can stem used in Microsoft APIs. The only other real option IMO is IsRetrievable (from Aziz) which somehow seems too linguistically twisted!