Java - неуниверсальный класс расширяет универсальный класс

Question

Java - неуниверсальный класс расширяет универсальный класс

1

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

Чтобы быть конкретным, у меня есть abstract class Stack<Type> со всеми необходимыми методами, и я хотел бы иметь class StackInteger то время как экземпляр StackInteger также является экземпляром Stack<Integer>.

Я вижу, я могу сделать что-то вроде этого:

class StackInteger {
    Stack<Integer> s;

    public StackInteger(int size) {
        s = new Stack<Integer>(size);
    }

}

а затем реализовать все методы Stack, чтобы содержать s.method(); но я задаюсь вопросом, могу ли я сделать это легко, простираясь от Stack.

dannymo 27 март 2015, в 23:23

Источник

3

Есть ли конкретная причина, по которой вы хотите это сделать? Из приведенного вами примера все, что вы делаете, это маскируете Stack<Integer> с двумя меньшими символами ...
Jon Egeland 27 март 2015, в 22:15
0

Тогда я могу иметь, например, StackInteger и StackString, которые оба реализуют свои собственные методы, но имеют общую функциональность Stack.
dannymo 27 март 2015, в 22:48
1

@dannymo проблема в том, что если вам нужно обработать только стек, то есть общую обработку как для StackString, так и для StackInteger, то вы не сможете это сделать, потому что StackString не является StackInteger.
Federico Peralta Schaffner 28 март 2015, в 00:27

Показать ещё 1 комментарий

Теги:

java

class

generics

inheritance

3 ответа

Ещё вопросы

Есть ли конкретная причина, по которой вы хотите это сделать? Из приведенного вами примера все, что вы делаете, это маскируете Stack<Integer> с двумя меньшими символами ...
Тогда я могу иметь, например, StackInteger и StackString, которые оба реализуют свои собственные методы, но имеют общую функциональность Stack.
@dannymo проблема в том, что если вам нужно обработать только стек, то есть общую обработку как для StackString, так и для StackInteger, то вы не сможете это сделать, потому что StackString не является StackInteger.

rgettman · Answer 1 · 2015-03-27T19-36-00.000Z

3

Да, в этом случае наследование является лучшим решением, чем состав, как у вас, потому что StackInteger - это Stack.

Просто поставьте Integer как аргумент типа в предложении extends.

class StackInteger extends Stack<Integer>

Однако, если вы не предоставляете каких-либо дополнительных функций помимо того, что уже есть в Stack, этот класс бесполезен, и вы можете просто использовать Stack<Integer>.

rgettman 27 март 2015, в 19:36

2

Кроме того, если вам нужно использовать Stack<Integer> предпочтите эквивалентную реализацию Deque поскольку она обеспечивает более полный и согласованный набор операций стека LIFO.
M.K. 27 март 2015, в 22:22
0

Это анти-паттерн, см. Ibm.com/developerworks/library/j-jtp02216
Federico Peralta Schaffner 27 март 2015, в 22:29
0

Это работает, как и ожидалось, когда я делаю StackInteger st = new StackInteger(3); однако, когда я делаю Stack st = new StackInteger(3); Я могу вставить любой тип в стек без проблем. Почему это возможно, когда st является экземпляром StackInteger, поэтому это экземпляр Stack <Integer>, даже если указатель является только стеком?
dannymo 27 март 2015, в 22:42
2

Это потому, что вы используете необработанную форму класса Stack . Происходит стирание типа, и T становится Object (верхняя граница). Вместо этого используйте Stack<Integer> st = new StackInteger(3); ,
rgettman 27 март 2015, в 22:43
0

@dannymo, читай пункт 23 Не используйте необработанные типы в новом коде, в эффективной Java.
M.K. 27 март 2015, в 22:49
0

Кто это проголосовал? Это правильный ответ на фактический вопрос.
Paul Boddington 27 март 2015, в 22:50
0

@pbabcdefp Скорее всего, это был Магнамаг. Я увидел, что репутация этого пользователя, как показано в этом вопросе, снизилась с 2135 до 2133 после того, как наши ответы были опущены.
rgettman 27 март 2015, в 22:52
0

@rgettman да, это был я. Сожалею. Просто я думаю, что это не очень хороший ответ. Как я сказал в своем ответе и как объясняет Брайан Гетц в статье, я предоставил ссылку, переход от универсального типа к маске информации о типе является антипаттермом. На самом деле, довольно плохой.
Federico Peralta Schaffner 27 март 2015, в 23:26

Показать ещё 6 комментариев

Federico Peralta Schaffner · Answer 2 · 2015-03-27T19-27-00.000Z

Я бы рекомендовал не распространять общие классы, чтобы преодолеть многословность. Это антипаттерн, известный как антипаттер псевдотипа.

Из статьи:

если параметр метода имеет тип StringList, вы не можете передать ему обычный список. Это означает, что вы вообще не можете использовать псевдотипы как аргументы метода, не требуя, чтобы каждое использование этого метода использовало псевдотип, что в практическом смысле означает, что вы вообще не можете использовать псевдотипы в библиотечных API.

...

Еще одна проблема с antipattern псевдо-typedef заключается в том, что он имеет тенденцию игнорировать преимущество использования интерфейсов для определения типов переменных и аргументов метода. Хотя можно определить StringList как интерфейс, который расширяет List и конкретный тип StringArrayList, который расширяет ArrayList и реализует StringList, большинство пользователей антипаттера псевдоспециалистов обычно не идут на эту длину, так как цель этой техники заключается в том, чтобы упростить и сократить имена типов. В результате API будут менее полезными и более хрупкими, поскольку они используют конкретные типы, такие как ArrayList, а не абстрактные типы, такие как List.

Итак, почему бы не придерживаться Stack<Integer>? Я не думаю, что это так плохо.

Paul Boddington · Answer 3 · 2015-03-27T20-37-00.000Z

Да, ты можешь сделать это.

class StackInteger extends Stack<Integer> {
    ....
}

Как указывает @Magnamag, это часто считается антипаттерном. Это особенно верно, если это делается только для того, чтобы не указывать параметры типа.

Однако для этого могут быть законные способы. Например, если не-общий класс является private, пользователи класса будут вынуждены программировать интерфейс (или абстрактный класс) в любом случае. В этом примере (по общему признанию, довольно надуманный) существует статический метод, возвращающий не общий универсальный класс, расширяющий AbstractList<String>.

public class Main  {

    public static List<String> helloWorld() {
        return new AbstractList<String>() {
            @Override
            public String get(int i) {
                switch (i) {
                    case 0: return "Hello";
                    case 1: return "World";
                    default: throw new ArrayIndexOutOfBoundsException();
                }
            }
            @Override
            public int size() {
                return 2;
            }
        };
    }

    public static void main(String[] args) {
        System.out.println(helloWorld());
    } 
}