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

    +80

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    if ( response == null || request == null ) {
      return;
    }

    if ( request.getHeader() != null
      && request.getHeader().getChannel() != null
      && request.getHeader().getChannel().getSubChannel() != null
      && request.getHeader().getChannel().getSubChannel().getSubChannel() != null
      && request.getHeader().getChannel().getSubChannel().getSubChannel().getName() != null
      && !request.getHeader()
        .getChannel()
        .getSubChannel()
        .getSubChannel()
        .getName()
        .equalsIgnoreCase( "XXX" ) ) {
      if ( response.getResponseObject() != null
        && response.getResponseObject().getReservation() != null
        && response.getResponseObject().getReservation().getRate() != null
        && response.getResponseObject().getReservation().getRate().getRoom() != null
        && response.getResponseObject()
          .getReservation()
          .getRate()
          .getRoom()
          .getBedType() != null ) {
        response.getResponseObject()
          .getReservation()
          .getRate()
          .getRoom()
          .setBedType( null );
      }
    }

    Индус. Спасибо что два if'a

    Запостил: madhead, 03 Июля 2013

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

    • ava wvxvw 03.07.2013 23:39 # +3

      Человек просто запарился исключения обрабатывать, вот и психанул...
      Ответить

      • ava madhead 04.07.2013 00:06 # +1

        Не представляете, насколько правы! В проекте весь код такой - с постоянными проверками. А по факту - из этого кода ничего и не выкинешь :(
        Ответить

      • ava santa_microbe 04.07.2013 12:33 # +2

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

    • ava Lure Of Chaos 04.07.2013 00:10 # +1

      проверки на нуллы - это хорошо. плохо, что каждый раз раз заново методы вызываются.
      а вдруг объект станет нуллом между проверками?
      Ответить

    • ava Sh1tM4ker 04.07.2013 09:06 # +3

      > .setBedType( null );
      Fatality!
      Ответить

      • ava madhead 04.07.2013 09:40 # 0

        Спокуха, там в другом месте проверка стоит
        Ответить

    • ava tir 04.07.2013 09:21 # 0

      request.getHeader().getChannel().getSubC hannel().getSubChannel().getName()
      response.getResponseObject().getReservat ion().getRate().getRoom().setBedType(val ue)

      вот такие цепочки действительно ГК
      Ответить

      • ava guest 05.07.2013 13:46 # 0

        А как надо?
        Ответить

        • ava tir 05.07.2013 15:06 # +1

          В идеале не более одного вызова метода.

          Если имеем такие цепочки, то скорее всего:
          - архитектура не продумана
          - присутствует высокая связанность в системе
          - код тяжело сопровождать и рефакторить.

          П. С. Если кому интересно могу привести многобуквенный пример с иллюстрацией, почему это плохо.
          Ответить

          • ava guest 05.07.2013 15:19 # 0

            Ну расскажи.
            Ответить

            • ava tir 05.07.2013 15:29 # +1

              Есть бухгалтер из ЖКХ, которая выставляет счета за электроэнергию. У нее есть бабушка на побегушках, которая снимает показания счетчиков.

              Допустим, необходимо получить показания счетчиков на ул. Ленина, д. 1, кв. 1

              При вышеописанной архитектуре это будет выглядеть примерно так:
              бабушка
              .выйдиВоДвор
              .сядьНаТроллейбус
              .проедь2Остановки
              .перейдиДорогу
              .найдиДом.зайдиВНего
              .найдиСчетчик.перепишиПоказания
              .вернисьОбратно.скажиМне

              Другими словами, бухгалтер руководит тем, как бабушке достать необходимые данные. Бухгалтер зависит от этой конкретной бабушки с ее умениями и навыками.
              Ответить

              • ava roman-kashitsyn 05.07.2013 15:35 # 0

                Мне кажется, не показательный пример. Чем это отличается от

                бабка.выйдиВоДвор()
                бабка.сядьНаТроллейбус()
                бабка.проедьДоОстановки("ул. Ленина")
                бабка.перейдиДорогу()
                бабка.найдиДом()
                бабка.войдиВДом()
                бабка.перепишиПоказания()
                показания = бабка.нуЧтоТамНасмотрела()
                Ответить

            • ava tir 05.07.2013 15:35 # 0

              Теперь немного переделаем архитектуру бухгалтерии. Дадим бабушке новый скил "дайПоказанияСчетчика(адрес)".

              Теперь работа бухгалтера сводится к:
              бабушка.раздобудьПоказанияСчетчика(адрес )

              Профит! Бухгалтеру теперь глубоко плевать как бабушка будет доставать эти показания. Для бухгалтера важны только показания, и она ничего не хочет знать о способе их получения. Теперь бухгалтер может работать практически с любой бабушкой (например, с бабушкой-телепатом). И пусть теперь бабушка сама решает как ей доставать показания.

              Как-то так.
              Ответить

              • ava tir 05.07.2013 15:38 # 0

                быдлоБабка.раздобудьПоказания(адрес) {
                return показанияЕсть.аЕслиНайду?
                }
                Ответить

              • ava guest 05.07.2013 21:53 # +1

                А что можно почитать о подобных архитектурных фокусах на русском?
                Ответить

                • ava tir 06.07.2013 10:47 # +1

                  что-нибудь конкретное назвать затрудняюсь. Как обычно: Джошуа Блох, Джоэл Спольски, паттерны и т. п.

                  В данном примере это просто нарушение инкапсуляции. Кто-то под инкапсуляцией понимает только то, что не надо делать public поля. Это не совсем верно. Если у вас на все private поля есть public геттер, то о инкапсуляции приходить не приходится. Вы просто завернули кишки в целофан и выставили их наружу.

                  Классический пример: добавление ребенка в коллекцию родителя. Наиболее частая реализация:
                  parent.getChildren().add(child)

                  Даже этот пример можно считать нарушением инкапсуляции, т. к. вы решаете, как родитель должен добавлять себе детей. Правильнее было бы:
                  parent.addChild(child)

                  Такое решение дает один весомый плюс: родитель полностью контролирует добавление ребенка.
                  Ответить

                  • ava eth0 06.07.2013 17:42 # +2

                    > контролирует добавление ребенка
                    А вот ИРЛ получается не у всех.
                    Ответить

                    • ava guest 06.07.2013 18:04 # +2

                      И ИРЛ его не соберет сборщик мусора, если на него не ссылается родитель.
                      Ответить

          • ava roman-kashitsyn 05.07.2013 15:21 # 0

            По-умному это называется принцип Law of Demeter. Приходилось работать с подобным кодом, приятного мало.
            Ответить

      • ava guest 06.07.2013 15:31 # 0

        А чем плоха такая цепочка?
        response.reservation.rate.room

        По сути - struct, а геттеры т.к. ява не может в свойства, а прямой доступ давать не надо.
        Ответить

    • ava krypt 04.07.2013 16:44 # 0

      Хе, вот именно поэтому мне и нравится Obj-C, который возвращает 0, если вызвать метод у nil.
      А то за условиями настоящего гк не видно.
      Ответить

      • ava madhead 04.07.2013 16:45 # 0

        В других языках под жава-платформу тоже есть такая фича.
        Ответить

    • ava guest 05.07.2013 08:52 # −2

      правильно:
      null != ....
      Ответить

      • ava krypt 05.07.2013 11:01 # 0

        Вы так привыкли != так правильно.
        Вы случаем не разработчик jslint, который выбрасывает на эту конструкцию ошибку вместо предупреждения, причём не отключаемую?
        Ответить

        • ava SmackMyBitchUp 14.07.2013 01:00 # 0

          Можно подробнее про этот забавный (я без иронии) случай.
          Ответить

      • ava bormand 05.07.2013 11:42 # +1

        А какая в жопу разница null != a или a != null? Это же не жабосравнение строк через equals(), в котором йода стайл имеет смысл. a = null и a == null жаба, емнип, все равно спутать не даст, выдав ошибку.
        Ответить

        • ava guest 05.07.2013 12:03 # −1

          спутает, особенно если код пишется ночью.
          Ответить

          • ava bormand 05.07.2013 12:15 # 0

            == вместо =: https://ideone.com/2jpuMr
            = вместо ==: https://ideone.com/gHoHhC

            Вот только так можно запороть: https://ideone.com/m60J5N
            Но с true и false никто на == сравнивать никто не будет, поэтому пример явно надуманный.

            Итого: спутать == и = в жабе практически нереально, и йода стайл для == не нужен. А для != - тем более, вы что-ли боитесь ! потерять в нем? ;)

            P.S. Да и в сишке\крестах тоже лет 10 как не нужен, если читать ворнинги.
            Ответить

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