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

    +79

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    /**
     * @return
     * true - если все строчки выделены,
     * false - если все строчки не выделены,
     * null - если есть как выделенные, так и не выделенные строчки
     */
    private Boolean lookRowsDownwards(ColumnHolder rowHolder, boolean isPreviousRowsSelected) {

    это реализация переключателя с 3-мя состояниями

    Запостил: Demetr, 06 Июля 2011

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

    • Да да да. дверь: открыта, закрыта, не закрыта. Помним скорбим.
      Ответить
      • ColumnHolder rowHolder
        меня тоже порадовал
        Ответить
        • Такое ощущение, что класс реализован не как ColumnHolder, а как SomeshitHolder.
          Либо после рефакторинга класс стал иметь более универсальную реализацию, но про название забыли или на него забили.
          Ответить
    • Ну и? А как бы вы реализовали возврат одного из 3 вариантов?
      Ответить
      • enum
        Ответить
        • Boolean.TRUE, Boolean.FALSE, null — чем не enum?
          Ответить
          • Тогда и int - enum, и вообще всё, что имеет конечное кол-во состояний.
            Ответить
            • В некоторых переносимых ассемблерах так и есть.
              Ответить
      • enum, int, битовая маска - зависит от ситуации, в данном случае enum. Возвращать null - это в высшей степени тайное знание, особенно если учесть, что в некоторых местах boolean, а не Boolean
        Ответить
        • показать все, что скрытоВ данном случае Boolean. Не нужен был бы null — было бы boolean.

          По сути, Boolean — трехзначный тип.
          Ответить
          • Херасебе, я думал Boolean - класс
            Ответить
          • Не удивляйтесь, когда следующие разработчики найдут Вас и будут бить ногами
            Ответить
            • Поищите использование Boolean в стандартных библиотеках. И задумайтесь, почему не используется boolean.
              Ответить
              • Поискал, посмотрел.
                " boolean " 3116 раз
                " Boolean " 141 раз

                с возможным null не увидел использования, проглядел штук 20 случайным образом, только там, где надо объект возвращать. Ах, да, ещё " Boolean." 242 раза для выражений Boolean.TRUE и Boolean.False.

                Что я делаю неправильно?
                Ответить
                • Странно, я нашёл тыщи полторы использований.

                  Первое же в возвращаемом значении: AbstractXMLSchema.getFeature. Дальше ImageIO.CacheInfo.getHasPermission, XMLComponent.getFeatureDefault (и перегрузка в дюжине классов), Timer.getFixedRate.

                  Среди членов-данных GroupLayout.ComponentInfo.honorsVisibili ty, NimbusDefaults.DerivedFont.bold и т.д.
                  Ответить
                  • В любом случае меньше чем кол-во примеров использования базового типа.
                    А сколько среди этого всего с возвратом null?
                    Да и чего вы тут развели. Это же вообще дебильный эстетический вопрос. Я вот раньше просто не додумывался, что можно использовать Boolean и возвращать null. Просто потому, что не было необходимости делать подобное. Теперь знаю. Вам спасибо. Буду делать так, ежели необходимо вернуть состояние "не закрыта".
                    Ответить
                    • Все перечисленные примеры — где Boolean легально может быть null (и часто это наиболее типичное значение и значение по-умолчанию). Я не включил многочисленные примеры использования null в Boolean для отложенной инициализации (это можно было бы сделать и парой boolean) и вынужденное использование в генериках и рефлексии (это ограничения языка).

                      Никто и не утверждает, что это нужно часто, но бывает. Используется для возврата состояния не открыто или закрыто, а «фиг его знает, спёрли шкатулку». Если где встречается Boolean, нужно задуматься, а не может ли он быть null, и устроит ли нас NullPointerException.
                      Ответить
                    • иногда вообще бывает удобнее использовать Boolean, Integer, Float и т. д. именно за счет того, что они могут быть null. Например, при сериализации в xml. null - означает, что в объекте это поле не задано и оно не должно отображаться. В случае с обычными int, float, boolean такое реализовать достаточно гемморно. Или, например, когда надо отличать ввод пользователя.
                      Ответить
          • Сижу битый час придумываю где бы "трехзначный тип" использовать.
            Видимо, далеко мне еще до вашего New School. Или я просто не готов видеть в своих проектах модель поведения: открыто, закрыто, не закрыто ^_^

            А вообще, как по мне, дак вы придаете излишнюю смысловую нагрузку простецкому классу-обертке.
            Ответить
            • Думайте ещё.
              Ответить
              • Не минусуйте дедушку, он мне паравозик в детстве подарил дело говорит.
                Ответить
            • надо целый час думать, а не битый :)
              Ответить
            • иногда удобно использовать в варианте: да/нет/не указано. Городить для этого енум мне обычно впадлу.

              П. С. Метод приватный + есть жавадок, вообще не вижу проблемы
              Ответить
              • Благодарю, разобрался в себе, ушел нажрался
                Ответить
              • >иногда удобно использовать в варианте: да/нет/не указано.
                Лучше использовать паттерн ValueContainer/Option/Optional/Nullable используется как некое_значение_любого_типа/не указано.
                Ответить
                • Если pulic api, то лучше. А если внутренняя реализация, да всего 1-2 раза вызывается - городить ради этого новый класс - по мне это оверинжиниринг.
                  Ответить
                  • >городить ради этого новый класс - по мне это оверинжиниринг.
                    ВоВо. А эти паттерны уже реализованы в большинстве библиотек.
                    Ответить
                    • подключать библиотеку ради одного места?
                      Ответить
                      • Почему одного? Может быть ради многих мест.
                        И да, в части языков - это есть в стандартной библиотеке.

                        Уж что, что, а городить велосипед ради одного места точно не стоит. Лучше воспользоваться либой.
                        Ответить
                        • Мои аргументы.

                          Часто бывает надо работать с коллекциями. В java.utils.* действительно нет многого. Давайте подключим либу, например, Apache Collections. Все хорошо, пока не понадобился метод, которого нет в Apache, но он есть в Guava. Ну, давайте еще и Guava подключим. Мы счастливы, мы не изобретаем велосипед. Но вот опять встает задача, для которой нет метода в либе, но он есть еще в каких-либо collections. Давайте и их подключим. В итоге выходит, что подключена куча либов, которые на 90% если не больше делают одно и тоже. Помимо коллекций надо работать еще и со строками, и с xml и с прочей всякой фигней. И либы растут как снежный ком. Растет размер приложения. Если работает команда разработчиков, то каждый начинает использовать разные либы. Теряется общий стиль кода. Кому-то нравится new ArrayList(), кому-то Lists.arrayList(), кому-то Collections.newArrayList() или подобная фигня. Усложняется понимание кода, т. к. в разных либах методы делающие одно и то же часто называются по-разному, т. е. программисту дополнительно надо держать это в голове. Засирается PermGen. Когда программа не укладывается в 256Mb PermGen'а, это уже перебор.

                          Поэтому иметь самописный метод, проверяющий, что строка не пустая - это нормально. Пока нужен лишь один этот метод.

                          Подключение любой либы должно быть осмысленным, целесообразность должна быть доказана.
                          Ответить
                          • в целом согласен, но есть небольшой ньюанс. Как правило, библиотеки вроде apache commons предназначены для определенной цели. И приложение тоже решает задачу из той же области - поэтому, вероятность того, что библиотека, подключенная ради одного места, будет полезна и во втором, и в третьем, пятом, десятом местах, достаточно высока.
                            Ответить
                            • Я не говорю, что бибилиотеки это зло. просто библиотеку надо подключать, когда в ней ДЕЙСТВИТЕЛЬНО есть потребность. а не когда ты будешь использовать 1% от нее. Причем если на написание этого 1% у тебя уйдет 2 минуты времени.

                              Очень часто бывает, что пригоняют ядерную боеголвку, когда достаточно было рогатки.
                              Ответить
                              • тогда см. мои следующие комментарии.

                                Вот когда-то мне нужен был простенький логгер. Что бы не подключать всякие log4j, как мне показалось, достаточно громоздкие, я написал маленький велосипед gargoyle.util.log.Log с одним СТАТИЧНЫМ методом Log.log(String,LEVEL);

                                Потом он немного разросся. И теперь в большинстве случаев он не нужен :)
                                Ответить
                                • С нижеизложенными комментариями согласен.

                                  Логгер - это уже фреймворк. Вот тут уж точно изобретать велосипеды не стоит. Это как свой jpa писать, или di-фреймворк, или xml парсить.

                                  Просто надо выбирать один инструмент, и его использовать до тех пор, пока нет весомых аргументов в пользу другого.
                                  Ответить
                                  • > Логгер - это уже фреймворк

                                    не согласен в терминологии. Логгер - это библиотека. Разница (может быть, только для меня) в том, что фреймворк, в отличии от библиотеки, навязывает свою логику работы приложения (смежное, особенно для веба, понятие - IoC).
                                    И если смена библиотеки относительно безболезненна (чаще просто хватает поменять имена), то смена фреймворка скорее аналогична переписыванию приложения.
                                    Ответить
                                    • Фреймоворк скорее навязывает логику использования себя. Просто бывают тяжеловесные фреймворки: hibernate, ejb и т. п. достаточно сильно влияющие на написание приложения, и легковесные, тот же log4j, javamail, влияющие в куда меньшей мере.

                                      Фреймворк, в моем понимании, несет набор законченой функциональности.

                                      П. С. Погуглил, в очень многих местах написано log4j - logging framework
                                      Ответить
                                      • ммм, ладно, убедили, спасибо.

                                        п.с. неважно, как во многих местах написано, важно, как называют на офсайте:
                                        "The products of the Apache Logging Services Project included four logging frameworks"
                                        (http://logging.apache.org/index.html)
                                        Ответить
                          • Как избежать перегрузки проекта одновременно не изобретая заново велосипеды?
                            Можно копировать нужный кусок из библиотеки, обрезая до собственной лайт-версии.
                            А если нужно изобретать свой велосипед -- то изучить подход в наиболее распространенных библиотеках, предоставляя похожий API - что бы, во-первых, не сбивать с толку остальных (сотрудников\поддержку\любопытных), во-вторых, что бы безболезненно подключить соотв. библу, когда это уже будет целесообразно
                            Ответить
                          • по этому поводу мне вспомнилась довольно устаревшая уже морально библиотечка xLib (cross-browser.com), которая, правда не на джаве, а на джаваскрипт - но там предлагался инструмент сборки проекта, который анализировал исходники, и в продакшен-версию кроме минимизации еще оставлял только те функции из библиотеки, которые использовались в приложении (плюс зависимости).
                            Неплохо бы такой же подход применять и в Джаве тоже
                            Ответить
                            • Такая штука уже давно есть ) в свободное время пишу патчи в apache poi, там есть тула, которая собирает облегчённую версию библиотеки ooxml, включая только рельно "нужные" классы. Причём без анализа исходников. Вот линк на реализацию:

                              https://github.com/apache/poi/blob/trunk/src/ooxml/java/org/apache/poi/util/OOXMLLite.java

                              Единственное условие - код должен иметь хорошее покрытие тестами, так как при вычислении "нужных" классов анализируются классы, загруженные в процессе тестирования.
                              Ответить
            • Там галочка, когда выбраны не все
              Ответить
    • а я тоже так делаю
      Ответить
    • Функция приватная, может даже используется в одном месте, поэтому сойдёт, имхо.

      Хотя лучше бы int'ом сразу вернуть количество выделенных строчек.
      Ответить
    • Класс ))))) 3 события + возвращает объект Boolean для null, это он классно придумал. Супер.
      Ответить
    • показать все, что скрытоvanished
      Ответить

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