Несколько методов toString () с универсальными - PullRequest
1 голос
/ 03 октября 2011

У меня есть объект, который будет храниться в двух разных структурах данных.

Я использую дженерики, и каждая структура должна распечатывать объект по-своему.Есть ли способ иметь несколько toString() методов, которые будут вызываться соответственно?

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

Должен ли я просто создать два разных объекта с разными toString() методами для каждой структуры данных?Или есть альтернатива?

Спасибо

Ответы [ 2 ]

2 голосов
/ 03 октября 2011

Я думаю, что вам нужно использовать toString() различных объектов, но вы все равно сможете сделать это с помощью дженериков.

Я полагаю, у вашего универсального класса есть хотя бы один экземпляр универсального типа. Если это так, переопределите ваши универсальные классы toString() для делегирования экземпляру объекта универсального типа.

Если ваш универсальный класс имеет только один экземпляр, вы можете сделать что-то вроде этого:

class Holder<T> {
    private T instance;

    public Holder(T _instance) {
        instance = _instance;
    }

    public String toString() {
        return instance.toString();
    }
}

И если в вашем классе есть несколько экземпляров универсального типа (как и у многих Collection), вы можете делегировать каждому экземпляру типа.

class CollectionHolder<T> {
    private Collection<T> collection;

    public CollectionHolder(Collection<T> _collection) {
        collection= _collection;
    }

    public String toString() {
        StringBuilder builder = new StringBuilder();
        for(T t : collection) {
            builder.append(t); //same as builder.append(t.toString())
        }
        return builder.toString();
    }
}
1 голос
/ 03 октября 2011

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

class Nay1 {

    String someCrazyMethod() { return "ugh"; }
}

class Nay2 {

    String someRandomMethod() { return "ook"; }
}

Ну, это отстой. Вы не хотели бы, чтобы Nay1 оук, или Nay2, чтобы тьфу. Но вам нужно что-то равномерное!

интерфейс NayInterface {

String nayRepresentation();

}

И ваши новые классы:

class Nay1 implements NayInterface  {

    String someCrazyMethod() { return "ugh"; }

    public String nayRepresentation() { return someCrazyMethod(); }
}

class Nay2 implements NayInterface {

    String someRandomMethod() { return "ook"; }

    public String nayRepresentation() { return someRandomMethod(); }
}

Теперь, несмотря ни на что, вы можете позвонить myNayInterface.nayRepresentation();, чтобы получить строковое представление, соответствующее соответствующему классу, без выполнения приведения.

class ActuallyDoesSomething<T extends NayInterface> {

    String foo;

    public ActuallyDoesSomething(T t) {
        this.foo = t.nayRepresentation();
    }

    public String foo() { return foo; }

}

Очевидно, что если вы хотите использовать toString () вместо nayRepresentation, вы можете сделать это. Но это позволит вам не использовать toString и сохранять его вместо этого для целей отладки.

...