Почему выбрана именно такая реализация?

public String toString() {
        Iterator<E> i = iterator();
    if (! i.hasNext())
        return "[]";

    StringBuilder sb = new StringBuilder();
    sb.append('[');
    for (;;) {
        E e = i.next();
        sb.append(e == this ? "(this Collection)" : e);
        if (! i.hasNext())
        return sb.append(']').toString();
        sb.append(", ");
    }

В проектировании еще не достаточно силен, поэтому начал понемногу смотреть реализацию сложных механизмов Java. И естественно спрашивать советы у более опытных товарищей. Ниже приведу свой вариант и свои мысли, интересует code review и пояснения почему было сделано именно так, а не иначе.

public String toString() {
        //Экономим на создании итератора, когда он не нужен, да и читаемость выше, на мой взгляд
        if(isEmpty())
            return "[]";

    StringBuilder sb = new StringBuilder();
    sb.append('[');
    
    //Не понимаю, почему используется конструкция for(;;), а не хотя бы while(i.hasNext())
    for(E e: this)
        {
        sb.append(e == this ? "(this Collection)" : e);
        sb.append(", ");
    }

    return sb.append(']').toString();

Здравствуйте, Tricks_Ter, Вы писали:

T_T>

T_T>public String toString() {
T_T>        //Экономим на создании итератора, когда он не нужен, да и читаемость выше, на мой взгляд
T_T>        if(isEmpty())
T_T>            return "[]";

T_T>    StringBuilder sb = new StringBuilder();
T_T>    sb.append('[');
    
T_T>    //Не понимаю, почему используется конструкция for(;;), а не хотя бы while(i.hasNext())
T_T>    for(E e: this)
T_T>        {
T_T>        sb.append(e == this ? "(this Collection)" : e);
T_T>        sb.append(", ");
T_T>    }

T_T>    return sb.append(']').toString();
T_T>

Прирост производительности будет не заметен, если вообще будет. И в вашем коде, даже после последнего элемента будет запятая ([a,b,c,]).

Здравствуйте, UDI, Вы писали:

UDI>Прирост производительности будет не заметен, если вообще будет. И в вашем коде, даже после последнего элемента будет запятая ([a,b,c,]).
Ну и к тому же в исходном коде, одни условием проверяется и выход их цикла и наличие запятой, а for (;) вообще ничего не проверяет, по-моему решение крутое:

if (! i.hasNext())

Здравствуйте, Tricks_Ter, Вы писали:

T_T>Почему выбрана именно такая реализация?
Возможно, потому что когда ее писали, ни isEmpty(), ни Iterable не было.

T_T>В проектировании еще не достаточно силен, поэтому начал понемногу смотреть реализацию сложных механизмов Java. И естественно спрашивать советы у более опытных товарищей. Ниже приведу свой вариант и свои мысли, интересует code review и пояснения почему было сделано именно так, а не иначе.

У вас тернарный оператор. Я бы на code review заставил переделать.

Здравствуйте, LeonidV, Вы писали:

LV>Здравствуйте, Tricks_Ter, Вы писали:

T_T>>Почему выбрана именно такая реализация?
LV>Возможно, потому что когда ее писали, ни isEmpty(), ни Iterable не было.

Кстати, да, читал упоминания о том, что до Java 1.2 коллекции выглядели иначе. Только потом ввели общий каркас. С другой стороны в интерфейсе Collection метод isEmpty() есть, можно старые версии посмотреть. Любопытно же.

For each действительно недавно ввели, но он через while прекрасно раскладывается, а судя по коду итераторы уже были.

T_T>>В проектировании еще не достаточно силен, поэтому начал понемногу смотреть реализацию сложных механизмов Java. И естественно спрашивать советы у более опытных товарищей. Ниже приведу свой вариант и свои мысли, интересует code review и пояснения почему было сделано именно так, а не иначе.

LV>У вас тернарный оператор. Я бы на code review заставил переделать.

Как говорится, подробности в студию! Честно скажу, что иногда люблю попользоваться тернарными операторами, не вижу в этом ничего ужасного, да и удобно. Хотя тут действительно не лучший вариант использования приведен.

Здравствуйте, Tricks_Ter, Вы писали:


LV>>Возможно, потому что когда ее писали, ни isEmpty(), ни Iterable не было.
T_T>Кстати, да, читал упоминания о том, что до Java 1.2 коллекции выглядели иначе. Только потом ввели общий каркас. С другой стороны в интерфейсе Collection метод isEmpty() есть, можно старые версии посмотреть. Любопытно же.

Значит я со string попутал.

LV>>У вас тернарный оператор. Я бы на code review заставил переделать.

T_T>Как говорится, подробности в студию! Честно скажу, что иногда люблю попользоваться тернарными операторами, не вижу в этом ничего ужасного, да и удобно. Хотя тут действительно не лучший вариант использования приведен.
ПМСМ, сильно снижается читаемость кода. Это весьма холиварный вопрос. Но в своих проектах я тернарный оператор использовать запрещаю.

for(E e: this) — вот этот кусок кода использует итераторы

Здравствуйте, Tricks_Ter, Вы писали:

T_T>В проектировании еще не достаточно силен, поэтому начал понемногу смотреть реализацию сложных механизмов Java. И естественно спрашивать советы у более опытных товарищей. Ниже приведу свой вариант и свои мысли, интересует code review и пояснения почему было сделано именно так, а не иначе.

Во-первых это не проективроние. Во-вторых не ясно какой цели вы добивались и добились ли. Так переливание из пустого в порожнее. Принципиальной разницы не видно.

Здравствуйте, Аноним, Вы писали:

А>for(E e: this) — вот этот кусок кода использует итераторы

Да, это for each. Его недавно ввели, если память не изменяет в Java SE 5 вроде. С другой стороны for each всегда можно разложить в виде:

Collection c = ...;

Iterator i = c.iterator();

while(i.hasNext())
{
    Object obj = i.next();
}

Так что тут проблемы вроде нет.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Tricks_Ter, Вы писали:

T_T>>В проектировании еще не достаточно силен, поэтому начал понемногу смотреть реализацию сложных механизмов Java. И естественно спрашивать советы у более опытных товарищей. Ниже приведу свой вариант и свои мысли, интересует code review и пояснения почему было сделано именно так, а не иначе.

B>Во-первых это не проективроние. Во-вторых не ясно какой цели вы добивались и добились ли. Так переливание из пустого в порожнее. Принципиальной разницы не видно.

Ну, лично меня в целом интересует научиться грамотно (очень!) строить архитектуру программного проекта. На мой взгляд, это нужно делать так:
* Читать подходящие книжки: Банда Четырех, Хорстманн, Фаулер, e.t.c.;
* Естественно тренироваться самому;
* Смотреть как реализованы удачные и сложные библиотеки. Java Collections по моему к ним как раз относится.

Вопрос заключался в том, что "вот тут сделано так, а я бы сделал иначе. Мне не понятно почему реализовано именно так, может чего-то из джедайских техник пока просто не замечаю я. Просветите, если видите".

Да, и просто пообщаться, кто бы как сделал. Может что-то новое для себя открою.

Здравствуйте, UDI, Вы писали:

UDI>Здравствуйте, UDI, Вы писали:

UDI>>Прирост производительности будет не заметен, если вообще будет. И в вашем коде, даже после последнего элемента будет запятая ([a,b,c,]).
UDI>Ну и к тому же в исходном коде, одни условием проверяется и выход их цикла и наличие запятой, а for (;) вообще ничего не проверяет, по-моему решение крутое:

UDI>

if (! i.hasNext())

Да, тоже теперь оценил. Даже других вариантов не приходит в голову, как можно сделать столь же изящно.

Здравствуйте, Tricks_Ter, Вы писали:

T_T>Ну, лично меня в целом интересует научиться грамотно (очень!) строить архитектуру программного проекта. На мой взгляд, это нужно делать так:
T_T>* Читать подходящие книжки: Банда Четырех, Хорстманн, Фаулер, e.t.c.;
T_T>* Естественно тренироваться самому;
T_T>* Смотреть как реализованы удачные и сложные библиотеки. Java Collections по моему к ним как раз относится.

Архитектура это классы и их взаимодействие. Реализация одного мелкого метода это кодинг. Даже на дизайн не очень-то тянет.

Здравствуйте, Blazkowicz, Вы писали:


B>Архитектура это классы и их взаимодействие. Реализация одного мелкого метода это кодинг. Даже на дизайн не очень-то тянет.

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

Здравствуйте, Tricks_Ter, Вы писали:
T_T> //Экономим на создании итератора, когда он не нужен, да и читаемость выше, на мой взгляд
T_T> if(isEmpty())
T_T> return "[]";

Это ведь AbstractCollection, то есть реализация по-умолчанию для всех потомков-коллекций, среди которых может быть класс, у которого скорость выполнения метода size() есть O(n). Если при этом метод isEmpty() вызывает size() (такое решение напрашивается), то имеем потерю в производительности там, где её можно избежать.

On 31/08/10 18:17, andrey_nado wrote:

> Это ведь *AbstractCollection*, то есть реализация по-умолчанию для всех
> потомков-коллекций, среди которых может быть класс, у которого скорость
> выполнения метода *size()* есть /O/(/n/). Если при этом метод
> *isEmpty()* вызывает *size()* (такое решение напрашивается), то имеем
> потерю в производительности там, где её можно избежать.
С другой стороны iterator() создаёт объект, а этого можно избежать для пустой коллекции. А isEmpty() "плохая" по времени коллекция может переопределить и обеспечить эффективную реализацию.