Почему Java Collections не являются универсальными методами удаления?

Почему Collection.remove (Object o) не является универсальным?

Похоже, Collection<E>мог иметьboolean remove(E o);

Затем, когда вы случайно попытаетесь удалить (например) Set<String>вместо каждой отдельной строки из a Collection<String>, это будет ошибкой времени компиляции, а не проблемой отладки позже.

Джош Блох и Билл Пью ссылаются на эту проблему в Java Puzzlers IV: Справочная угроза фантома, Атака клона и Месть сдвига .

Джош Блох говорит (6:41), что они пытались обобщить метод get из Map, метод remove и некоторые другие, но «это просто не сработало».

Существует слишком много разумных программ, которые нельзя было бы генерировать, если вы разрешаете только универсальный тип коллекции в качестве типа параметра. Приведенный им пример является пересечением a Listof Numbers и a Listof Longs.

remove()( Mapкак и в Collection) не является универсальным, потому что вы должны иметь возможность передавать объект любого типа remove(). Удаленный объект не обязательно должен быть того же типа, что и объект, которому вы передаете remove(); это только требует, чтобы они были равны. Из спецификации remove(), remove(o)удаляет объект eтаким, какой (o==null ? e==null : o.equals(e))есть true. Обратите внимание, что нет ничего требующего oи eбыть того же типа. Это следует из того факта, что equals()метод принимает в качестве Objectпараметра, а не просто тот же тип, что и объект.

Хотя обычно может быть верно, что многие классы equals()определили так, что его объекты могут быть равны только объектам своего собственного класса, что, конечно, не всегда так. Например, спецификация for List.equals()говорит, что два объекта List равны, если они оба являются списками и имеют одинаковое содержимое, даже если они являются разными реализациями List. Итак, возвращаясь к примеру в этом вопросе, можно иметь Map<ArrayList, Something>и для меня вызов remove()с LinkedListаргументом as, и он должен удалить ключ, представляющий собой список с тем же содержимым. Это было бы невозможно, если бы они remove()были общими и ограничивали тип аргумента.

Потому что, если ваш параметр типа является подстановочным знаком, вы не можете использовать универсальный метод удаления.

Кажется, я вспоминаю, что столкнулся с этим вопросом с помощью метода get (Object) Map. Метод get в этом случае не является универсальным, хотя следует ожидать, что ему будет передан объект того же типа, что и параметр первого типа. Я понял, что если вы передаете вокруг Карт с подстановочным знаком в качестве параметра первого типа, то нет способа извлечь элемент из Карты с помощью этого метода, если этот аргумент был универсальным. Аргументы подстановочных знаков не могут быть действительно удовлетворены, потому что компилятор не может гарантировать, что тип является правильным. Я предполагаю, что причина добавления является общей, что вы должны гарантировать, что тип правильный, прежде чем добавлять его в коллекцию. Однако, при удалении объекта, если тип неправильный, он все равно ничего не будет соответствовать.

Я, наверное, не очень хорошо это объяснил, но мне это кажется достаточно логичным.

В дополнение к другим ответам есть еще одна причина, по которой метод должен принимать Objectпредикаты. Рассмотрим следующий пример:

class Person {
    public String name;
    // override equals()
}
class Employee extends Person {
    public String company;
    // override equals()
}
class Developer extends Employee {
    public int yearsOfExperience;
    // override equals()
}

class Test {
    public static void main(String[] args) {
        Collection<? extends Person> people = new ArrayList<Employee>();
        // ...

        // to remove the first employee with a specific name:
        people.remove(new Person(someName1));

        // to remove the first developer that matches some criteria:
        people.remove(new Developer(someName2, someCompany, 10));

        // to remove the first employee who is either
        // a developer or an employee of someCompany:
        people.remove(new Object() {
            public boolean equals(Object employee) {
                return employee instanceof Developer
                    || ((Employee) employee).company.equals(someCompany);
        }});
    }
}

Дело в том, что объект, передаваемый removeметоду, отвечает за определение equalsметода. Построение предикатов становится очень простым.

Предположим , один имеет коллекцию Cat, а некоторые ссылки на объекты типов Animal, Cat, SiameseCatи Dog. Спрашивать коллекцию, содержит ли она объект, на который указывает ссылка Catили, SiameseCatкажется разумным. Спросить, содержит ли он объект, на который Animalссылается ссылка, может показаться странным, но это все же вполне разумно. В конце концов, рассматриваемый объект может быть Catи может появиться в коллекции.

Кроме того, даже если объект оказывается чем-то отличным от a Cat, нет проблем с тем, чтобы сказать, появляется ли он в коллекции - просто ответьте «нет, это не так». Коллекция «lookup-style» некоторого типа должна быть способна осмысленно принимать ссылку любого супертипа и определять, существует ли объект в коллекции. Если переданная ссылка на объект имеет несвязанный тип, коллекция не сможет его содержать, поэтому запрос в некотором смысле не имеет смысла (он всегда будет отвечать «нет»). Тем не менее, поскольку нет никакого способа ограничить параметры подтипами или супертипами, наиболее практично просто принять любой тип и ответить «нет» для любых объектов, тип которых не связан с типом коллекции.

Я всегда думал, что это потому, что у remove () нет причин заботиться о том, какой тип объекта вы ему предоставите. Независимо от этого достаточно легко проверить, является ли этот объект одним из объектов, содержащихся в Collection, поскольку он может вызывать equals () для чего угодно. Необходимо проверить тип в add (), чтобы убедиться, что он содержит только объекты этого типа.

Это был компромисс. Оба подхода имеют свои преимущества:

• remove(Object o)
  • является более гибким. Например, он позволяет перебирать список чисел и удалять их из списка длинных.
  • код, который использует эту гибкость, может быть легко обобщен
• remove(E e) обеспечивает большую безопасность типов для того, что большинство программ хотят делать, обнаруживая незаметные ошибки во время компиляции, например, ошибочно пытаясь удалить целое число из списка шортов.

Обратная совместимость всегда была главной целью при разработке Java API, поэтому было выбрано remove (Object o), потому что это облегчало генерирование существующего кода. Если бы обратная совместимость не была проблемой, я предполагаю, что дизайнеры выбрали бы remove (E e).

Remove не является универсальным методом, поэтому существующий код, использующий неуниверсальную коллекцию, будет по-прежнему компилироваться и иметь то же поведение.

См. Http://www.ibm.com/developerworks/java/library/j-jtp01255.html для получения подробной информации.

Редактировать: комментатор спрашивает, почему метод add является универсальным. [... удалил мое объяснение ...] Второй комментатор ответил на вопрос от firebird84 намного лучше меня.

Другая причина - из-за интерфейсов. Вот пример, чтобы показать это:

public interface A {}

public interface B {}

public class MyClass implements A, B {}

public static void main(String[] args) {
   Collection<A> collection = new ArrayList<>();
   MyClass item = new MyClass();
   collection.add(item);  // works fine
   B b = item; // valid
   collection.remove(b); /* It works because the remove method accepts an Object. If it was generic, this would not work */
}

Потому что это сломало бы существующий (до Java5) код. например,

Set stringSet = new HashSet();
// do some stuff...
Object o = "foobar";
stringSet.remove(o);

Теперь вы можете сказать, что приведенный выше код неверен, но предположим, что o произошел от разнородного набора объектов (т. Е. Он содержал строки, числа, объекты и т. Д.). Вы хотите удалить все совпадения, что было допустимо, потому что при удалении игнорировались бы не строки, потому что они были неравны. Но если вы удалите его (String o), это больше не работает.