Java 中的过滤器 java.util.Collection
我编写了一个util类来过滤java.util.Collection中的元素，如下所示：
public class Util{
public static <T> void filter(Collection<T> l, Filter<T> filter) {
Iterator<T> it= l.iterator();
while(it.hasNext()) {
if(!filter.match(it.next())) {
it.remove();
}
}
}
}
public interface Filter<T> {
public boolean match(T o);
}
问题：
- 您认为有必要编写该方法吗？
- 方法上有什么改进吗？
I wrote a util class to filter elements in java.util.Collection as follows:
public class Util{
public static <T> void filter(Collection<T> l, Filter<T> filter) {
Iterator<T> it= l.iterator();
while(it.hasNext()) {
if(!filter.match(it.next())) {
it.remove();
}
}
}
}
public interface Filter<T> {
public boolean match(T o);
}
Questions:
- Do you think it's necessary to write the method?
- Any improvement about the method?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您应该允许任何
Filter不仅仅是Filter。客户端可能还希望有一个返回新 Collection 的方法：
You should allow any
Filter<? super T>not justFilter<T>.Clients might also want to have a method that returns a new Collection instead:
Iterables.filter(iterableCollection, predicate)其中Predicate实现过滤Iterables.filter(iterableCollection, predicate)where thePredicateimplements the filtering是否有必要取决于您想要实现的目标。如果您可以使用其他第三方库（例如 Google Collections），则不需要。如果计划是一次性的，那么可能不会。如果您计划创建不同的过滤器，那么是的，这看起来是保持事物模块化和内聚性的好方法。
一个建议 - 您可能想要返回一个集合 - 这样，您可以选择返回一个新的过滤集合，而不是改变原始集合。如果您需要在并发上下文中使用它，这可能会很方便。
您还可以查看对这个类似问题的回复< /a>.
Whether it's necessary depends on what you want to achieve. If you can use other third party libs like Google Collections, then no. If it's planned to be a one-off, then probably not. If you plan on creating different filters, then yep, looks like a good approach to keep things modular and cohesive.
One suggestion - you might want to return a Collection - that way, you have the option of returning a new filtered Collection rather than mutating the original Collection. That could be handy if you need to use it in a concurrent context.
You might also look at the responses to this similar question.
关于问题1，已经有很多馆藏库了。过滤是由 apache common-collections CollectionUtils 和 google 集合 可迭代。
Regarding question 1 there are already a lot of collection libraries. Filtering is offered by instance by apache common-collections CollectionUtils and google collections Iterables .
看起来不错 - 但我们无法决定是否“有必要”编写它（好吧，你确实写了它；））
remove()方法并不总是实现，它被标记为 （可选）。有些迭代器只是抛出UnsupportedOperationException。您应该捕获它或将其转换为自定义异常，表示无法过滤此集合。然后您可以将方法签名更改为，
因为迭代器不限于集合。使用此实用方法，您可以过滤每个提供允许删除操作的迭代器的“容器”。
Looks nice - but we can't decide, if it's 'necessary' to write it (OK, you actually wrote it ;) )
The
remove()method is not always implemented, it is labelled (optional). Some Iterators just throw anUnsupportedOperationException. You should catch it or convert it to a custom exception saying, that this collection can't be filtered.And then you could change the method signature to
because iterators are not limited to Collections. With this utility method you could filter every 'container' that provides an iterator which allows remove operations.
如果您不介意使用第三方库，那么不。
对提供此功能的第三方库的一些建议：
您可能需要查看提供
filter< 的 Functional Java /code> 以及在真正的蓝色函数语言中发现的许多其他高阶函数。示例：
另一种选择是使用 lambdaj - 一个具有类似目标但比功能性更简洁的库爪哇。不过 lambdaj 的覆盖范围不如函数式 Java 那么多。
例子：
If you don't mind using a third party library then no.
Some suggestions for third party libraries that provide this functionality:
You might want to look at Functional Java which provides
filterplus many other higher order functions found in true-blue functional languages.Example:
Another alternative is using lambdaj - a library with similar goals but is much more concise than Functional Java. lambdaj doesn't cover as much ground as Functional Java though.
Example:
我认为在
Filter接口中定义一个visit(T o)方法会很酷。这样，过滤器实现可以决定当存在匹配时对访问的对象采取什么操作。I think it would be cool to have a
visit(T o)method defined in yourFilter<T>interface. That way the filter implementation can decide what action to take on the visited object when there is a match.