views:

84

answers:

3

I am working on a library that will contain many filter methods.

I have seen many project that use this syntax for filters

public Foo GetFooByBar(bar);

In other project people use this syntax

public Foo GetFooWithBar(bar);

Since this library will be reused by many other developers I wanted to know which one developers feel more comfortable with.

Please let me know which you prefer and if possible why.

Thanks

EDIT: The first few answers suggest just overloading a GetFoo method to accept various arguments. This works well for a standard interface in a language that supports overloading. But in my case some I will also have some more fluent apis so I will want to link various filters like this

Foo GetFoo().ByBar(bar).ByBaz(Baz); or Foo GetFoo().WithBar(bar).WithBaz(baz);
+5  A: 

This may not be popular, but I like

public Foo GetFoo();
public Foo GetFoo(Bar bar);
public Foo GetFoo(Baz baz);

No need for an extra "ByWhatever", overloading is enough.

I'm not really sure why I like this, it's probably because I dislike redundancy, and the argument is already saying enough.

If the current language supports no overloading and you need more than one type of filter for the same object, then I prefer

public Foo GetFooByBar(Bar bar)

By suggests to me better the real meaning of the method.

EDIT: In fluent interfaces I prefer much more strongly the By option. With looks like it's adding something, instead of filtering, like "Get me a hot dog with ketchup".

Vinko Vrsalovic
So many lazy programmers is it really that hard to imcludethe by or with bot as part of the method name. There is no sensible reason why one would make such a naming decision except laziness. Come on it's not that hard and IDE complete the method names it's not like you actually end up typing the whole thing anyway.
mP
The sensible reason is stated in the answer, to avoid redundancy.
Vinko Vrsalovic
@mP: "Every good programmer is a lazy programmer" (not necessarily the other way around though!)
peSHIr
@peSHIR - thats so wrong because so many people take that literally and try and be smarty asses and deliver broken code, minimal doco and make life hard for the next developer. That statement is supposed to be able DRY not being lazy and deliverying C.R.A.P.
mP
+2  A: 

IMO, GetFooByBar suggests "filter Foo using Bar as some kind of condition"... but GetFooWithBar suggests that Bar is some extra (optional) information that can come back with a Foo - i.e. GetOrderWithLines...

At a push, I'd use By - but in general? nothing at all; the fact that the parameter is a Bar should suggest enough.

The only time this gets tricky is when you have an API that doesn't support method overloads - basic SOAP, for example. Then you might need different ByX, ByY methods.

Marc Gravell
I agree on that. For me the presence of the parameter is enough.
crauscher
But if one just looks at a stacktrace you can't tell which method was actually executed without intimate knowledge of the importance of the parameter types. Method names should be descriptive, is it really that hard to type "find with name" instead of get. After all the return type is already in the signature so there is no need to call the method getThing() it could be reduced to g() after all it doesn't return void so it must be a getter.
mP
A: 

Some of the other answers are wrong, overloaded methods should result in the same answer. If different parametersresult in different filter conditions then you have basically done the wrong thing. Overloading should basically only exist as a means of doing studff like offering sensible defaults, type conversions and so on. Most of the time there will be one method with the bulk of the code , with the others doing a little massaging, setting up defaults or whatever and then invoking the main method.

That said, I would probably call my methods, "withId", "withSurname" only because I think with implies that the found entity has that Id or name. By seems not quite as accurate in describing the predicate. In the end the most important thing is to be consistent.

mP
They do result in the same answer type, that is, a Foo instance. In the backstage you'd have a FilterFoo() method that accepts any filter and behaves accordingly, with the different overloads just a thin wrapper over it.
Vinko Vrsalovic
For an outside coder unaware of your requirements and having never ad your documentation(javadoc) they would know that the methods worked totally differently, one filtering by this, another by that. You cant tell by looking at the method name. The whole point of naming is so the name conveys what the thing represents or do. Your naming only tells half the story. Its not a competition on terse naming.You may as well call your methods doStuff() after all its correct - all methods do stuff, but the real info about "what stuff" is being done requires one to look at the code or docs.
mP
As you can see for the other answers and the voting, many coders would expect this behavior only from seeing overloads in the IDE. It's not a competition on redundancy either. It's a fact that at least some other 6 people will deduce this behavior just fine from the overloads, which are available via a proper IDE without having to read documentation. And your reductio ad absurdum is absurd, what's being proposed here does tell you the whole story, you just dislike it or find it unintuitive.
Vinko Vrsalovic
And What if your looking at a stack trace - where you dont get the parameter types ? Its nicer to be able to tell whats going on without an IDE.
mP