返回具有相似参数的不同类型的方法的命名约定

发布于 2024-11-03 07:27:51 字数 607 浏览 0 评论 0 原文

我有一个 SearchService,它使用一种算法来查询数据库并返回结果。数据可以以多种不同的格式返回,具体取决于调用者想要从服务中获得什么。这些格式是:

  • 直接与数据库中的表匹配的实体列表
  • 匹配的记录的主键(长整型)列表
  • “搜索结果”列表,由一组通常与以下内容相关的字段组成用户希望从搜索结果中看到什么(例如人名、地址、电话号码等)

目前我的 SearchService 如下所示:

public interface SearchService {
    public List<People> searchPeopleReturnEntity(SearchRequest request);
    public List<Long> searchPeopleReturnId(SearchRequest request);
    public List<SearchResult> searchPeopleReturnSearchResult(SearchRequest request);
}

我正在寻找有关此方面最佳实践的建议。目前,命名约定似乎相当笨拙,我相信有比我现在更好的解决方案。

I have a SearchService which uses an algorithm for querying a database and returing the results. There are a couple of different formats the data can be returned as, depending on what the invoker wants from the service. These formats are:

  • A list of entities that directly match against a table in the database
  • A list of primary keys (Longs) of the records that match
  • A list of 'search results' which is composed of a bunch of fields that are generally relevant to what a user would want to see from a search result (say a persons name, address phone number etc)

Currently my SearchService looks like:

public interface SearchService {
    public List<People> searchPeopleReturnEntity(SearchRequest request);
    public List<Long> searchPeopleReturnId(SearchRequest request);
    public List<SearchResult> searchPeopleReturnSearchResult(SearchRequest request);
}

I'm looking for advice on best practices regarding this. Currently the naming convention seems pretty clunky and I believe there is a better solution than what I have now.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

七秒鱼° 2024-11-10 07:27:51

我将它们称为简单的名称,例如 getPeoplegetIdsgetSearchResults

如果您需要对除人之外的实体使用这 3 个相同的方法,我会考虑制作一些通用的中间类型来定义它们,允许您编写如下内容:

List<People> people = service.getPeople(request).asEntities();
List<Long> fooIds = service.getFoos(request).asIds();

// or something like this
List<People> people = service.searchPeople().getEntities(request);

I'd call them something simple like getPeople, getIds, getSearchResults.

If you need these same 3 methods for entities other than people, I'd consider making some generic intermediate type defining them, allowing you to write something like this:

List<People> people = service.getPeople(request).asEntities();
List<Long> fooIds = service.getFoos(request).asIds();

// or something like this
List<People> people = service.searchPeople().getEntities(request);
野却迷人 2024-11-10 07:27:51

我将它们称为 findPeople()findPeopleIDs()findPeopleResults()

I'd call them findPeople(), findPeopleIDs() and findPeopleResults().

何以心动 2024-11-10 07:27:51

如果您的服务还可以返回其他实例(除了 People),我会将它们命名为

  • findPeopleEntities()
  • findPeopleIds()
  • getSearchResult() 或 getPeopleSearchResult() (您通常找不到搜索结果;) )

如果 SearchResult 仅用于人员,我还将其命名为 PeopleSearchResult。否则,我会给它一个通用参数,例如 SearchResult ,然后 List> getPeopleSearchResult()。

If your service can return other instances as well (besides People), I'd name them

  • findPeopleEntities()
  • findPeopleIds()
  • getSearchResult() or getPeopleSearchResult() (you generally don't find search results ;) )

If SearchResult is used for people only, I'd also name it PeopleSearchResult. Otherwise I'd give it a generic parameter like SearchResult<T> and then List<SearchResult<People>> getPeopleSearchResult().

梦中楼上月下 2024-11-10 07:27:51

或者您可以使用 searchBy... 方法?尽管我同意这表示您将返回相同的结果。
也许你可以重构一下:

  • search... 将返回一个列表(我猜测 ID 在数据库中?),
  • 然后添加一个 getPeople( List ),它实际上返回这些 ID 的对象列表,

因此你的 search... 方法总是返回 ID,然后您有专门的函数将它们转换为“正确的”搜索结果?

or you can use the searchBy... approach? though I agree that denotes you will return same results.
Perhaps you can refactor a bit:

  • search... will return a List (I'm guessing ID's in the database?)
  • then add a getPeople( List ) which actually returns the list of objects for those ID's

so your searc... methods always return ID's and then you have specialized functions to transform those into "proper" search results?

无声无音无过去 2024-11-10 07:27:51

如果不是很明显,这种方法没有真正的“最佳实践”命名方案。

In case it isn't obvious, there is no real "best practice" naming scheme for this kind of method.

黎夕旧梦 2024-11-10 07:27:51

一种想法可能是:

public <T> T findPeople(SearchRequest request, Class<T> resultClass);

然后您可以根据 resultClass 是 Person.class、Long.class 还是 SearchResult.class 返回不同的内容。

或者,不那么可怕的是,您可以这样做:

public <T> T findPeople(SearchRequest request, ResultConverter<T> resultConverter);

其中 ResultConverter 是一个接口,它接受某种原始搜索结果并返回合适的转换结果。您可以为常见的实例提供固定的实例:

public class ResultConverters {
    public static final ResultConverter<Long> ID;
    public static final ResultConverter<Person> PERSON;
    public static final ResultConverter<SearchResult> SEARCH_RESULT;
}

One idea might be:

public <T> T findPeople(SearchRequest request, Class<T> resultClass);

You can then return different things according to whether resultClass is Person.class, Long.class, or SearchResult.class.

Or, less horribly, you could do:

public <T> T findPeople(SearchRequest request, ResultConverter<T> resultConverter);

Where ResultConverter is an interface which takes some sort of raw search result and returns a suitable converted result. You could have canned instances for the common ones:

public class ResultConverters {
    public static final ResultConverter<Long> ID;
    public static final ResultConverter<Person> PERSON;
    public static final ResultConverter<SearchResult> SEARCH_RESULT;
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文