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

    +76

    1. 1
    assertTrue(!reportDto.getOrder());

    Фантазия индусов неиссякаема. Перед написанием кода читать Упанишады до просветления.

    Запостил: roman-kashitsyn, 01 Декабря 2011

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

    • ava tir 01.12.2011 14:29 # −1

      и в чем ГК?
      Ответить

      • ava roman-kashitsyn 01.12.2011 14:33 # +2

        Ну, видимо, разработчик - очень позитивный человек, и потому не любит писать assertFalse. Да и название метода напрягает: разве можно по названию понять, что это boolean?
        Ответить

        • ava 3.14159265 01.12.2011 14:45 # 0

          Я тоже не люблю писать assertFalse.
          Я позитивный?
          Ответить

        • ava tir 01.12.2011 14:45 # 0

          а это JUnit? Просто в Eclipse RCP, к примеру, есть исключительно isTrue, isFalse не предусмотрено.

          С названием согласен. Хотя может используется какой-нить фреймворк, которому необходимо именование get/set? А is просто не поддерживается?
          Ответить

          • ava roman-kashitsyn 01.12.2011 14:58 # 0

            Да, это JUnit. Нет, все фрэймвёрки стандартные.
            Ответить

          • ava roman-kashitsyn 01.12.2011 15:08 # 0

            тут даже не в is дело, а в том, что вместо прилагательного имеем существительное
            Ответить

            • ava tir 01.12.2011 15:43 # 0

              можно подробнее про прилагательное и существительное?
              Ответить

              • ava roman-kashitsyn 01.12.2011 16:11 # 0

                boolean подразумевает наличие у объекта какого-то признака, обычно признаки выражаются с помощью прилагательных ("мягий?", "мелкий?", "корректный?", и т.д.). Если в boolean - существительное, значит, имеет место некая классификация по типу ("стол?", "файл?", "диван?"), что для строго типизированных языков у меня лично вызывает подозрение.
                Order - заказ, т.е. существительное. Поскольку я знаю контекст, могу сказать, что здесь должно быть прилагательное "заказан".
                Ответить

                • ava roman-kashitsyn 01.12.2011 16:25 # 0

                  > строго статически типизированных
                  selffix
                  Ответить

                  • ava absolut 01.12.2011 16:56 # 0

                    так а полиморфизм на что?
                    Ответить

                    • ava roman-kashitsyn 01.12.2011 17:03 # 0

                      >> у меня лично вызывает подозрение
                      > полиморфизм на что?
                      поясните мысль.
                      Ответить

                      • ava absolut 01.12.2011 17:18 # 0

                        >поясните мысль.
                        alexoy? :)
                        например, есть абстрактный класс - мебель. для него объявлены методы изСтол()/изДиван() ...
                        хотя, конечно, это у меня тоже вызывает подозрение :)
                        Ответить

                        • ava roman-kashitsyn 01.12.2011 17:24 # +2

                          Да, налицо ошибка дизайна.
                          Стол и диван - реализации, а методы могут быть, к примеру:
                          isSleepable()
                          isVisibleInTheDark()
                          isLovedByMyCat()
                          etc...
                          Ответить

                • ava tir 01.12.2011 17:38 # 0

                  ну вот и надо было про контекст чуть рассказать =)
                  Ответить

                • ava tir 02.12.2011 09:08 # 0

                  Существительные имеют право на жизнь. Как замена классам.
                  enum Type {  PHONE, NOTEBOOK }

class Device {
    Type type;

    boolean isPhone() { return type == Type.PHONE; }
    boolean isNotebook() { return type == Type.NOTEBOOK; }
}


                  Бывают ситуации, когда это намного удобнее, чем городить отдельные классы.
                  Ответить

                  • ava roman-kashitsyn 02.12.2011 10:10 # 0

                    > Бывают ситуации
                    Не встречал в языках с поддержкой ООП ситуаций, где это было бы удобнее. Ваш пример мне ничего не говорит. Ещё дедушка Бьярне завещал нам не использовать меток типа там, где возможно наследование.
                    в Clojure иногда есть смысл использовать их для мултиметодов, но это отдельная песня, так как мультиметоды нужны довольно редко
                    Ответить

                    • ava tir 02.12.2011 10:20 # 0

                      Т. е. в моем примере следовало бы создать двух наследников Phone и Notebook? Никаких новых методов для наследников не предполагается.
                      Ответить

                      • ava roman-kashitsyn 02.12.2011 10:37 # +1

                        Ваш пример мне ни о чём не говорит, потому что я не знаю, как будет использоваться Device. На данный момент он мне кажется совершенно бесполезным. Моделирование мира в виде таксономии - вещь не однозначная, можно предложить бесчисленное количество таксономий. Всё зависит от задачи, которую нам нужно решать.

                        Мысли вслух: поскольку у современных аппаратов довольно много функций, наверняка есть набор операций, которые вы хотите совершать с устройством. По мне так типы девайсов тут вообще особо не нужны, достаточно одного Device. В енум помещаем возможные типы операций, в Device помещаем методы
                        isSupportedOperation(OperationType t): boolean
                        executeOperation(OperationType t, Array[Object] args): void
                        getSupportedOperations(): Array[OperationType]
                        и объявляем два инстанса Device: phone и notebook, для которых определяем набор возможных операций.

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

                        • ava roman-kashitsyn 02.12.2011 10:49 # 0

                          P.S. инстансам phone и notebook всё равно придётся опредлять какую-то логику, специфичную для них. Тут либо использовать анонимные классы, либо уж честно наследоваться со всеми вытекающими.
                          Ответить

                        • ava tir 02.12.2011 10:55 # 0

                          давайте добавим два поля в Device: name и description. Обычные текстовые. Объекты будут используется только для справочной информации. Никаких типо-специфичных действий над ними не предполагается. Все что требуется - уметь различать девайсы по типам: телефон, ноутбук и т. д. Количество типов девайсов будет расти, но никакой девайсоспецифичной логики добавляться не будет.
                          Ответить

                          • ava roman-kashitsyn 02.12.2011 11:04 # +1

                            зачем уметь различать девайсы по типами, если никакой девайсоспецифичной логики добавляться не будет? Если нужно просто показать тип на UI, лучше уж просто хранить тип в виде строки или енума и указывать его при создании объекта.

                            Проблема с методами isXXX в том, что нужно будет менять ваш класс Device после добавления нового типа девайса. Если типов много, этот класс очень быстро превратиться в жуткое мясо, а код - в вермишель.
                            Ответить

                            • ava tir 02.12.2011 11:12 # 0

                              Различать, чтобы в UI иконки разные рисовать, группировку производить. Вот мы тип как enum и храним.

                              Метод isXXX по большей части как шорткат для type == Type.XXX. Например, для нескольких наиболее часто используемых все-таки лучше сделать шорткаты.
                              Ответить

                              • ava roman-kashitsyn 02.12.2011 11:24 # 0

                                По мне так в такой модели лучше вообще всё загнать в базу, а из объекта сделать обычную entity.
                                Ответить

                                • ava tir 02.12.2011 11:29 # 0

                                  Угу. Подводя итог всему вышесказанному:

                                  isСуществительное имеет право на жизнь, но только в специфических ситуациях.
                                  Ответить

                                  • ava roman-kashitsyn 02.12.2011 11:31 # +1

                                    и в этих редких случаях они отлично заменяются енумами и таблицами.
                                    Ответить

                            • ava gegMOPO4 03.12.2011 23:21 # 0

                              isDirectory()/isFile().
                              Ответить

                              • ava roman-kashitsyn 04.12.2011 14:07 # 0

                                >> файл?
                                > isDirectory()/isFile().
                                Да, я держал в уме эти методы. Есть мнение, что такое API выглядит кривоватым. Мне больше нравится, как это сделано в Python: модуль os.path умеет определять по заданному, является ли объект файлом или каталогом, а api класса File направлено на ввод-вывод в стиле юникса.
                                Ответить

                • ava tir 02.12.2011 09:18 # 0

                  П. С. Быть может и в вашем случае было примерно следующее: isOrder() трактуется не как "заказан", а как "заказ". Т. е. вроде как тип объекта поменялся. А до этого он был чем-то вроде "предзаказ". Такое поведение бывает ближе к реальной жизни: мы же говорим "послали заявку на бронирование", а после ее подтверждения мы говорим "у нас есть бронь", мы не говорим "у нас есть подтвержденная заявка". Хотя в коде объект остался тем же, просто поменялась пара полей.
                  Ответить

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