gpt4 book ai didi

java - 公开内部集合项时应该使用 Iterator 还是 Iterable?

转载 作者:塔克拉玛干 更新时间:2023-11-03 02:57:47 25 4
gpt4 key购买 nike

我有一个带有私有(private)可变数据列表的类。

我需要在以下条件下公开列表项:

  • 列表不应在外部修改;
  • 使用 getter 函数的开发人员应该清楚,他们获得的列表无法修改。

  • 应将哪个 getter 函数标记为推荐方法?或者你能提供更好的解决方案吗?
    class DataProcessor {
    private final ArrayList<String> simpleData = new ArrayList<>();
    private final CopyOnWriteArrayList<String> copyData = new CopyOnWriteArrayList<>();

    public void modifyData() {
    ...
    }

    public Iterable<String> getUnmodifiableIterable() {
    return Collections.unmodifiableCollection(simpleData);
    }

    public Iterator<String> getUnmodifiableIterator() {
    return Collections.unmodifiableCollection(simpleData).iterator();
    }

    public Iterable<String> getCopyIterable() {
    return copyData;
    }

    public Iterator<String> getCopyIterator() {
    return copyData.iterator();
    }
    }

    UPD:这个问题来自关于列表 getter 实现的最佳实践的真实代码审查讨论

    最佳答案

    “最佳”解决方案实际上取决于预期的应用程序模式(而不是像接近投票者所建议的那样取决于“意见”)。每个可能的解决方案都有可以客观判断的优缺点(而 由开发人员判断)。

    Edit: There already was a question "Should I return a Collection or a Stream?", with an elaborate answers by Brian Goetz. You should consult this answers as well before making any decision. My answer does not refer to streams, but only to different ways of exposing the data as a collection, pointing out the pros, cons and implications of the different approaches.



    返回迭代器

    仅返回 Iterator不方便,不管进一步的细节,例如是否允许修改。安 Iteratorforeach中不能单独使用环形。所以客户必须写
    Iterator<String> it = data.getUnmodifiableIterator();
    while (it.hasNext()) {
    String s = it.next();
    process(s);
    }

    而基本上所有其他解决方案都允许他们只写
    for (String s : data.getUnmodifiableIterable()) {
    process(s);
    }

    暴露一个 Collections.unmodifiable...查看内部数据:

    您可以公开内部数据结构,包装到相应的 Collections.unmodifiable... 中。 Collection 。任何修改返回集合的尝试都将导致 UnsupportedOperationException被抛出,明确说明客户端不应修改数据。

    此处设计空间的一个自由度是您是否隐藏其他信息:当您有 List 时,你可以提供一个方法
    private List<String> internalData;

    List<String> getData() {
    return Collections.unmodifiableList(internalData);
    }

    或者,您可以对内部数据的类型不太具体:
  • 如果调用者不能使用 List#get(int index) 进行索引访问方法,那么你可以将该方法的返回类型更改为 Collection<String> .
  • 如果调用者还不能通过调用 Collection'size() 获得返回序列的大小,那么你可以返回一个 Iterable<String> .

  • 还要考虑的是,当暴露不太具体的接口(interface)时,您以后可以选择将内部数据的类型更改为 Set<String> , 例如。如果您保证返回 List<String> ,然后稍后更改它可能会引起一些头痛。

    暴露内部数据的副本:

    一个非常简单的解决方案是只返回列表的副本:
    private List<String> internalData;

    List<String> getData() {
    return new ArrayList<String>(internalData);
    }

    这可能具有(可能大且频繁)内存复制的缺点,因此仅应在集合“小”时考虑。

    此外,调用者将能够修改列表,并且他可能希望更改反射(reflect)在内部状态中(事实并非如此)。可以通过将新列表额外包装到 Collections.unmodifiableList 中来缓解此问题。 .

    暴露一个 CopyOnWriteArrayList

    暴露一个 CopyOnWriteArrayList通过其 Iterator或作为 Iterable可能不是一个好主意:调用者可以选择通过 Iterator#remove 修改它调用,而您明确希望避免这种情况。

    暴露一个 CopyOnWriteArrayList的解决方法它被包裹成一个 Collections.unmodifiableList可能是一个选择。乍一看,它可能看起来像一个多余的厚防火墙,但它绝对是合理的 - 请参阅下一段。

    一般注意事项

    在任何情况下,您都应该虔诚地记录这种行为。特别是,您应该记录调用者是 不是 应该以任何方式更改返回的数据(无论是否可能而不会导致异常)。

    除此之外,还有一个令人不舒服的权衡:您可以在文档中准确无误,也可以避免在文档中公开实现细节。

    考虑以下情况:
    /**
    * Returns the data. The returned list is unmodifiable.
    */
    List<String> getData() {
    return Collections.unmodifiableList(internalData);
    }

    此处的文档实际上还应说明...
    /* ...
    * The returned list is a VIEW on the internal data.
    * Changes in the internal data will be visible in
    * the returned list.
    */

    考虑到线程安全和迭代期间的行为,这可能是一个重要信息。考虑一个循环,它对内部数据的不可修改 View 进行迭代。并考虑在这个循环中,有人调用了一个导致内部数据修改的函数:
    for (String s : data.getData()) {
    ...
    data.changeInternalData();
    }

    这个循环将以 ConcurrentModificationException 中断,因为内部数据在迭代时被修改。

    这里关于文档的权衡是指,一旦指定了某个行为,客户端将依赖于这个行为。想象一下客户端这样做:
    List<String> list = data.getList();
    int oldSize = list.size();
    data.insertElementToInternalData();

    // Here, the client relies on the fact that he received
    // a VIEW on the internal data:
    int newSize = list.size();
    assertTrue(newSize == oldSize+1);

    诸如 ConcurrentModificationException 之类的东西如果返回了内部数据的真实副本,或者使用 CopyOnWriteArrayList 就可以避免。 (每个包裹成一个 Collections.unmodifiableList )。在这方面,这将是“最安全”的解决方案:
  • 调用方无法修改返回列表
  • 调用者不能直接修改内部状态
  • 如果调用者间接修改了内部状态,那么迭代仍然有效

  • 但是人们必须考虑相应的应用案例是否真的需要如此多的“安全性”,以及如何以一种仍然允许更改内部实现细节的方式记录这一点。

    关于java - 公开内部集合项时应该使用 Iterator 还是 Iterable?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30194843/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com