Передающий суперкласс как параметр к методу, ожидающему sub класс

Необходимо попытаться реализовать только один метод:

class o {
AddBall(Ball b)
}

и попытайтесь полагаться на полиморфизм для другого поведения относительно различных классов. Конечно, детали зависят от реализации иерархии Ball.

Вы могли бы (или не мог бы) хотеть (часть) шаблон "посетитель".

Добавьте метод к Ball:

public abstract void addTo(o o);

Implementat в LegalBall и IllegalBall как

public void addTo(o o) {
    o.add(this);
}

Хорошо существует шаблон "посетитель", как упомянуто выше. Если Вы не можете или не хотеть изменять Шар, LegalBall или IllegalBall, то Вы могли бы попытаться иметь ответвление отдельного метода на основе на типе шара. Обратите внимание, что, если Вы позже добавляете QuasiLegalBall, этот код повредится. Общий случай, который Вы упоминаете, является трудным, потому что существование LegalBall и IllegalBall не предотвращает там бывшего Balls, которые не вписываются в два типа, которые Вы описали (с точки зрения языка, по крайней мере).

class o {
    public void AddBall(Ball b) 
    { 
        if (b instanceof LegalBall) {AddLegalBall(b); }
        else if (b instanceof IllegalBall) {AddIllegalBall(b); }
        else { /*error, new type of ball created*/ }
    }
    private void AddLegalBall(LegalBall b) { }
    private void AddIllegalBall(IllegalBall b) { }
    }
 }

Используйте шаблон "посетитель". Выполнение его без является громоздким, и было предметом этого вопроса: Работа вокруг диспетчеризации статического метода Java без Двойной Отправки/Шаблонов "посетитель".

Однако можно ли заявить исходную проблему? Я имею в виду, почему у Вас должны быть те две перегрузки для Добавить метода? Возможно, можно ли решить его совершенно другим способом, который не должен полагаться на динамическую отправку как шаблон "посетитель"?

Как Вы ожидаете, что это будет знать который звонить? Что устанавливает эти два метода независимо, что Вы ожидали бы, что это будет звонить один а не другой?

Я соглашаюсь с использованием Посетителя.

Дополнительно, если у Вас нет доступа к иерархии Ball (доступ исходного кода), или простой не испытывают желание изменять что-либо там; Вы могли изменить свой клиентский класс и решить оттуда.

Плохая вещь, конечно, Вы закончите со многими если/операторы else if.

Необходимо будет добавить, общий метод (добавьте (Шар)), и оттуда назовите другие. Это быстро, легко и грязно.

:)

public class Test {
    public static void main( String [] args ) { 
        Ball ball = new IllegalBall();
        Test test = new Test();
        test.add( ball );
        test.add( new IllegalBall() );
        test.add( new LegalBall() );
    }
    private void add( Ball ball ){
        System.out.println("Generic method: I'll have someone handling this : "  + ball );
        if( ball instanceof IllegalBall ) {
            add( ( IllegalBall ) ball );
        } else if( ball instanceof LegalBall ) {
            add( ( LegalBall ) ball );
        }
    }
    private void add( IllegalBall ball ){
        System.out.println("illega-ball: I won't do anything about it! " + ball );
    }
    private void add( LegalBall ball ) { 
        System.out.println("legal-ball: Hey this is legal I'll do my best!! " + ball );
    }
}

class Ball {}
class IllegalBall extends Ball {}
class LegalBall extends Ball {}

BTW, если у Вас нет ссылки непосредственно компилятором, отправит его в корректный метод как в последних 2 вызовах.

Поскольку Вы видите, что просто необходимо добавить следующий код:

private void add( Ball ball ){
    System.out.println("Generic method: I'll have someone handling this : "  + ball );
    if( ball instanceof IllegalBall ) {
        add( ( IllegalBall ) ball );
    } else if( ball instanceof LegalBall ) {
        add( ( LegalBall ) ball );
    }
}

Шаблон "посетитель" и аналогичные решения с помощью обратных вызовов, в этом случае только, кажется, пытаются изогнуть код таким способом заставить компилятор принимать дефектную иерархию классов.

Я сохранил бы тип Ball и сделал бы легальным/недопустимым свойство того типа. У Вас только был бы o.add (Шар), в котором Вы проверяете на легальный/недопустимый на основе некоторых свойств или через метод, isLegal (), например.

Если вышеупомянутый подход не кажется разумным, то не разумно иметь отдельный метод добавить два (очень) отличных типа, и отношения выделения подтипов, которые Вы предложили, не будут способом пойти.