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

    +77

    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
    public class SomeEntityBean implements javax.ejb.EntityBean {
        private boolean loadMember;
        private Wrapper list;
    
        /* ... */
    
        public void ejbLoad() {
            this.loadMember = false;
            load();
        }
    
        private void load() {
            /* a LOT of code */
            String[] attrList = this.loadMember ?  a.attrListMember() : a.attrList();
            this.list = new Wrapper(attrList);
            /* a LOT of code */
        }
    
        public Something getSomething() {
            /* a LOT of code */
            this.loadMember = true;
            load();
            /* do something with this.list */
            this.loadMember = false;
            return something;
        }
    }

    Имена персонажей были умышленно изменены.
    Разумеется, loadMember больше нигде не используется.
    Яркий пример повторного использования кода.

    Запостил: roman-kashitsyn, 16 Июня 2011

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

    • no excuses
      Ответить
    • Один я читаю ebjLoad именно так?
      Ответить
      • я даже в Вашем посте сначала ejb увиделбыдло не знающее о EJB детектед
        Ответить
    • String[] attrList = this.loadMember ? a.attrListMember() : a.attrList();
      С тем же успехом заменяется на: String[] attrList = a.attrListMember();
      Ибо перед вызовом метода load() из метода getSomething() loadMember всегда тру.
      Да и loadMember для меня в данном коде имеет странное назначение.

      Да и я не понял, зачем использовать ссылку на вызывающий объект - this. Этот момент прошу пояснить.

      ГК, короче.
      Ответить
      • Короче, народ, давайте так, что бы было честь по чести - минусанул - объясни. А то какие-то вы хитрожопые получаетесь :D
        Ответить
      • мои соображения :

        возможно a.attrListMember() - долгая операция, или ненужная, если вызов происходит не из getSomething(). Заметим, что метод load вызывается также и из ejbLoad(). Т. о. может это такой хитрый lazy loading?
        Ответить
        • В следующем не уверен:
          Настораживает this.list = new Wrapper(attrList);
          Ощущение такое, что программист очень надеется на то, что GC за ним мусор уберет.

          Посмотрел что же такое Wrapper - интерфейс. Значит имело место имплементирование
          class Wrapper implements java.sql.wrapper
          Теперь мы можем получить объект класса.
          Можно было бы придумать метод очистки содержимого объекта, а не выделять каждый раз память под новый объект. Если кто минусанет - пишите почему. Мне на карму похуй, хоть в минуса вгоните, мне важно что в коде творится на самом деле.
          Ответить
          • Расслабились, Wrapper это вымышленное имя. В оригинале было очень длинное название класса.
            Ответить
            • ох, темните вы...
              Ответить
              • Дык. Закрытый код, палиться нельзя ;)
                Ответить
                • Ну и нахуй вас таких шаолиней. Есть класс Wrapper - делайте метод очистки состояния объекта, а то каждый раз ссылку на новый кидают.
                  Ответить
                  • Да ладно Вам, тут не в этом суть. Хрен с ней с памятью, пусть GC подавиться (я, конечно, тоже обожаю С и привык аккуратно работать с памятью). Как в этом гавне разбираться, вот в чём вопрос.
                    Ответить
                    • Что значит "тоже обожаю Си"?
                      Это простое нормальное отношение к памяти. Да и где вообще логика - постоянно создавать новый объект используя конструктор с параметром. Такое ощущение, что настроить объект иначе - нельзя.
                      Ответить
                      • Удивляюсь, Вы всегда обращаете внимание не на то, что Вам пытаются донести. Манипуляции с памятью, на мой взгляд, именно в этом случае интересны в последнюю очередь.
                        Ответить
                • DEVPROM Интегрированная среда для управления Agile проектами
                  как будто сложно, чесслово...
                  Ответить
    • ГК-6969 - Во истину гомосексуально...
      Ответить
    • Если бы ещё load() не был private, можно было бы придумать объяснение этому костылю.
      Ответить
    • Все-таки думаю, что это жертва рефакторинга (причем не одного). Скорее всего на тот момент нельзя было написать void load(boolean loadMember) {...} и явно вызывать с true или false. Возможно было использование этого флага вне метода load. Потом код рефакторили, и в конце концов все выродилось в то что есть сейчас.

      П. С. За ГК не считаю. Я бы ввел термин "Жертва Рефакторинга".
      Ответить
      • Скорее, "жертва дебага", ибо рефакторинг в теории должен делать код лучше.
        Ответить
        • На практике, не всегда все бывает так глядко. Особенно, когда над проектом работает сразу 5-7 человек. Кто-то в рамках своей задачи подрефакторил один маленький кусочек, кто-то другой. А на выходе получается то что имеем.
          Ответить
        • И не только в теории, я вам скажу)))))
          Ответить
    • показать все, что скрытоvanished
      Ответить
    • показать все, что скрытоvanished
      Ответить

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