1. Java / Говнокод #15727

    +73

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    private static class Errors extends ArrayList<String> {
	private static final long serialVersionUID = 1L;
}

private static class Notices extends ArrayList<String> {
	private static final long serialVersionUID = 1L;
}

    две большие разницы

    Запостил: Lure Of Chaos, 11 Апреля 2014

    Комментарии (9) RSS

    • ava wvxvw 11.04.2014 14:48 # 0

      Ох, да, жизненно необходимая фича любого явакода - бойлерплейт для сериализации (говорять, что бесполезный в большинстве случаев, и, наверное где-то в настройках можно отключить это предупреждение... но как обычно, Ява ИДЕ предлагают интересную альтернативу в виде генерации псевдослучайных чисел специально для этого свойства.

      ПС. Я обычно пишу Foo.class.getHashCode() вместо.
      Ответить

      • ava roman-kashitsyn 11.04.2014 14:51 # 0

        > говорять, что бесполезный в большинстве случаев
        Да не то чтобы прям бесполезный. Вообще говоря, это версия, определяющая обратную совместимость.

        > Foo.class.getHashCode()
        hashCode() же
        Ответить

      • ava bormand 11.04.2014 15:23 # 0

        > для сериализации
        > Я обычно пишу Foo.class.getHashCode() вместо.
        This integer need not remain consistent from one execution of an application to another execution of the same application не смущает?

        http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode%28%29
        Ответить

        • ava roman-kashitsyn 11.04.2014 15:30 # +2

          Нет, ведь @wvxvw давно пользуется своим собственным умным семантическим форматом хранения данных, т.к. жабья сериализация недостаточно выразительна.
          Ответить

        • ava wvxvw 11.04.2014 16:29 # 0

          Обычно это свойство абсолютно не играет никакой роли (либо сериализация, как таковая не нужна, а нужен только интерфейс для каких-то невнятных методов, либо не использует это значение - как в том же JSON например). Да, я вообще имел в виду не class, а его имя. Ну да не важно на самом деле.

          Т.е. эти свойства только нужны (на сколько я понимаю) для Data{Output/Input}Stream. Которыми все равно никто не пользуется / область их применения сильно ограничена.
          Ответить

          • ava roman-kashitsyn 11.04.2014 16:48 # 0

            Ими пользуется например контейнер сервантлетов, в периоды печали сохраняющий сессионные данные на диск.
            Ответить

            • ava wvxvw 11.04.2014 16:58 # 0

              Хз. по-моемут тут сама по себе идея бессмысленная: ну поменял я лейаут классу, а версию забыл поменять - чем мне номер версии поможет? Поменял версию, но не поменял лейаут - вообще бессмысленная возможность. Если бы он сам мог вычислить версию, из, скажем, какой-нибудь нормальной формы, к которой он приводил сериализованое представление объекта, тогда это бы имело смсыл. А в том виде, в котором оно есть, полезности никакой.
              Ответить

              • ava roman-kashitsyn 11.04.2014 17:05 # +1

                Изменение класса без изменения версии имеет смысл. Допустим добавили новое поле, но считаем, что не очень страшно, если оно будет нулл/нуль. Сохранение версии позволит нам читать ранее записанные объекты без проблем.
                Если же считаем, что новое поле ни в коем случае не может быть нулл/нуль - обновляем версию, чтобы попытка чтения невалидных более старых данных сразу кидала исключение (fail fast).

                > Если бы он сам мог вычислить версию
                А он сам и вычисляет, рассчитывая хеши имён всех базовых классов и их полей и типов полей и хрен знает чего ещё. Скорее всего, магическое число, которое рисует эклипс по умолчанию - это и есть тот самый хеш.

                Идеи в целом разумные, но жабье исполнение как всегда "на высоте" - магические интерфейсы без методов, магические статические константы, магические приватные методы для кастомной сериализации - вся подсистема сериализации один сплошной 3.14здец.
                Ответить

                • ava wvxvw 11.04.2014 17:24 # 0

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

    Добавить комментарий