Jawa / Говнокод #8143 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  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
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
//javax.swing.JTree
            public void setBounds(Rectangle r) {
                AccessibleContext ac = getCurrentAccessibleContext();
                if (ac instanceof AccessibleComponent) {
                    ((AccessibleComponent) ac).setBounds(r);
                } else {
                    Component c = getCurrentComponent();
                    if (c != null) {
                        c.setBounds(r);
                    }
                }
            }
        
            public void setSize (Dimension d) {
                AccessibleContext ac = getCurrentAccessibleContext();
                if (ac instanceof AccessibleComponent) {
                    ((AccessibleComponent) ac).setSize(d);
                } else {
                    Component c = getCurrentComponent();
                    if (c != null) {
                        c.setSize(d);
                    }
                }
            }  
    

            public void requestFocus() {
                AccessibleContext ac = getCurrentAccessibleContext();
                if (ac instanceof AccessibleComponent) {
                    ((AccessibleComponent) ac).requestFocus();
                } else {
                    Component c = getCurrentComponent();
                    if (c != null) {
                        c.requestFocus();
                    }
                }
            }
    
            public void addFocusListener(FocusListener l) {
                AccessibleContext ac = getCurrentAccessibleContext();
                if (ac instanceof AccessibleComponent) {
                    ((AccessibleComponent) ac).addFocusListener(l);
                } else {
                    Component c = getCurrentComponent();
                    if (c != null) {
                        c.addFocusListener(l);
                    }
                }
            }
            public boolean isFocusTraversable() {
                AccessibleContext ac = getCurrentAccessibleContext();
                if (ac instanceof AccessibleComponent) {
                    return ((AccessibleComponent) ac).isFocusTraversable();
                } else {
                    Component c = getCurrentComponent();
                    if (c != null) {
                        return c.isFocusTraversable();
                    } else {
                        return false;
                    }
                }
            }

Запостил: 3.14159265 3.14159265, (Updated )

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

  • Кто-нибудь знает причину, по которой AccessibleComponent и Component в разных ветках иерархии классов?
    Ответить
    • AccessibleComponent - интерфейс, ничего общего не имеющий с Component, зато являющийся частью расширения javax Accessibility. Они и не должны быть в одной ветке = )
      Ответить
  • Столько копипаста и ведь сложно от него избавиться... через рефлексию можно, но тогда уж лучше копипаст...
    Ответить
    • А Вы не находите, что проблемы тут в проектировании?

      вот еще пример - InputStream и OutputStream implements Closeable
      А java.sql.Connection, java.sql.Statement и java.sql.ResultSet не реализуют этого интерфейса.
      Говорят в 7-ой жабе это пофиксили, но сколько ж лет оно так криво было.
      Ответить
      • Нахожу, собственно, поэтому задал вопрос выше.
        Дурно пахнущий код, который ещё и непонятно как рефакторить - явный признак ошибки на уровне архитектуры.
        Ответить
        • Ну в примере с Closeable - у меня сделано именно через рефлексию.
          Тут это слишком накладно м наверняка им стоило завести какой-то общий интерфейс.
          A <em>Component</em> is an object having a graphical representation
           * that can be displayed on the screen and that can interact with the
           * user. Examples of components are the buttons, checkboxes, and scrollbars
           * of a typical graphical user interface. <p>
           * The <code>Component</code> class is the abstract superclass of
           * the nonmenu-related Abstract Window Toolkit components. Class
           * <code>Component</code> can also be extended directly to create a
           * lightweight component. A lightweight component is a component that is
           * not associated with a native opaque window.
          
          
           The AccessibleComponent interface should be supported by any object 
           * that is rendered on the screen.  This interface provides the standard 
           * mechanism for an assistive technology to determine and set the 
           * graphical representation of an object.


          >>> A Component is an object having a graphical representation that can be displayed on the screen
          >>> The AccessibleComponent interface should be supported by any object that is rendered on the screen.
          >>>should be supported by any object that is rendered on the screen.
          >>>any object that is rendered on the screen

          Потому что тут явно у кого-то проблемы с логикой.
          Ответить
          • AccessibleComponent появился только в 1.2, а Component был с самого начала. Костыли всегда криво выглядят.
            Ответить
            • Т.е. включить Vector и прочие стэки в Collection Framework - это нормально, а добавить новый интерфейс к Component - никак by design?
              Ответить
              • новый интерфейс значит и реализацию, а это, может быть, не везде нужно )
                Ответить
              • Загадка. Я с accessibility не работал, не знаю всей глубины замысла. Вероятно, были серьёзные идеологические причины или это просто невозможно. Ведь если это ошибка, то исправить её можно было бы в любой момент.
                Ответить
      • Кстати, именно для решения таких косяков в Scala есть Structural Subtyping: входными параметрами функций могут быть любые типы, содержащие определённые методы, к примеру close:
        def using[T <: { def close(): Unit}, S](obj: T)
        Ответить
          • >Scala меня все больше интригует
            Кстати схожие ощущения.
            И по скорости исполнения тоже неплохо так смотрится. В отличии от Groovy.
            Ответить
            • я потихоньку стараюсь осваивать, правда, к сожалению, на работе пригодиться в обозримом будущем.
              Почти дочитал Programming in Scala, пока в восторге. Реально сокращает число букв, которые нужно набирать. Плюс есть полная обратная совместимость с Java. Единственный ощутимый косяк - нет пока нормальной IDE (язык настолько мощный, что я понимаю, почему её сложно сделать). Говорят, для IntelliJ IDEA есть нормальный плагин, но я его пока не пробовал. Поскольку пишу пока только игрушечный код, мне вполне хватает emacs + scala interpreter + maven.
              Ответить
        • я как-то думал о такой возможности -- а на те-ка, в Скале уже реализовано
          Ответить
      • Потому, что в Closeable close() throws IOException, а в java.sql.Statement — SQLException.
        Ответить
          • Имхо по уму checked exceptions максимум должны просто выдавать ворнинг "исключение не поймано", с отлючением вообще функции через свитч компилятора при прототипировании -- и всё. Было бы весьма полезно.
            Ответить
          • А зачем, какая причина порождать java.sql.Statement от Closeable? То, что название метода совпадает — просто случайность. Вот в семёрке причина появилась — и вели AutoCloseable.
            Ответить
            • >То, что название метода совпадает — просто случайность.
              Никак нет, сер. Там очень много классов с методом close.
              RMIConnection, например.
              public void close() throws IOException; а интерфейс не имплементит

              >А зачем?
              Обычно пресловутый Exception игнорится и если хочется чего-то закрыть нужно писать
              try{
              close(something);
              }catch(){}

              А если нужно закрыть PreparedStatement, а за ним Connection, или 2 Connection подряд приходится новое закрытие снова оборачивать в try-catch. По понятным причинам.

              А если оно все имплементит Closable делаем метод
              static void close(Closable cl){
              try{cl.close}catch(Exception e){};
              }
              или даже так
              static void close(Closable... cl){
              Ответить
              • Если бы Господь Гослинг хотел, чтобы исключения close() игнорировались, он бы создал close() не выбрасывающим исключения.
                Ответить
                  • Массивы появились до генериков (где ковариантность/контровариантность можно выразить через wildcards), и кажется варианта было тут только два:

                    1. Сделать их инвариантными, и заставить программиста вручную кастить каждую овцу к Mammal, что в отсутствии функциональных средств попродило бы кучу бойлерплейта, да еще и ударило бы по производительности

                    2. Сделать их ковариантными, и проверять в рантайме.

                    что они и сделали
                    Ответить
                • И какой процент случаев, когда они НЕ игнорируются?

                  Да и вообще речь о том, что если уж вводить новый интерфейс с методом
                  >close is invoked to release resources that the object is holding.
                  то стоит сделать его универсальным.
                  Ответить
                  • По-настоящему надёжный код не должен просто игнорировать исключение. Да, разумнее было бы в этом случае не исключение бросать, а код ошибки возвращать, но так уж… Не Javish.

                    Кстати, Closeable ведь только с 1.5. Вот и ответ на вопрос.
                    Ответить
                    • >По-настоящему надёжный код не должен просто игнорировать исключение

                      Да в большинстве случаев этот "надёжный код" просто выводит сообщение и закрывает программу. В принципе абсолютно то же самое происходит при стандартное поведении системы при непойманном исключении, только вот весёлый Гослинг заставляет нас писать больше букав просто так.

                      Если уж и заботиться о суперкритичном софте (типа софта для бирж), то можно было бы сделать свитч компилятора XX:+critical, который бы не компилировал код при непойманных исключениях, и XX:-critical, который бы просто выводил ворнинг. Выбирай нужный свитч под тип приложения.
                      Ответить
                • это явный косяк. В Spring, к примеру, вообще днём с огнём не встретишь checked исключений. Если у тебя ошибка закрытия файла (в жизни такого не видел), что ты можешь сделать как программист? Unchecked исключения можно ловить там, где это имеет смысл, а таскать checked исключения в сигнатурах методов через весь код очень неудобно.
                  Ответить
                    • Типа более надёжный код получается: форсим программиста обрабатывать ошибки, даже если он не знает, как. Хотели как лучше, получилось как всегда.
                      Ответить
                    • >и не забыть отловить все что вылетает
                      Как я уже сказал, можно было просто выводить ворнинг, а не вообще отказываться компилировать. Хорошие программисты обратят внимание на ворнинг, а плохие будут делать путые try...catch...finally в любом случае и при checked exceptions, ровно как и игнорировать ворнинги. Так что толка нет никакого.
                      Ответить
  • э$F FT)L.N.X,R(T)K,HI)C"D?C?T!V C N$L!R"D"P)D.C$K!W?J(G.N A?I:Z.H"R:F?G$LF X$E$O:P"U T)U E$N)Y!C"B,I:N.W"G.R?Q)I.O E!O B$S$S!O)Z?U"I"H?M,Z!L)HY,B"U:J"Y(S?T.Q,CP$C)V)Z:G,X"X,V$X!X H(L(J(BF"B.C Q!E?V:Z.C(A$A)P(D HH(G.H$C,I E.Z!J,S!S:T?G HA$K?L(C"P"L)E,N"M)ZO)V"Q:Y.D)B!Y)X!P:U$Z.M$A G!OK,L$T)S"D)Q!ZJ(M W"J,H"D:T,H O!V?V,A"Q$X(K?FO$CO?T?VN$T,K"S"I D?X$V!V!T?F E?N N,R.S,K"Z.LXF.W$D,G N(SA:L$W,F)G)MN)Y?U"Z(XF$R N:W NQ,D)DШJVOXNFJAARWAAOFDQH
    Ответить
    • Здесь нельзя взрывать. И собаку эту не ешь.
      Ответить
  • гей дев до добра не доводит

    Создателя успешных на Западе видеоигр обвинили в насилии
    Его жена рассказала, что он похитил ребенка и избил ее отца, а бывшие студенты говорят, что он совращал несовершеннолетних
    Ответить
    • Всё зло от игор. Запретить их надо.
      Ответить
  • Ihno,

    Я (фронтендер) в начале пути просто обожал миксины (подвид множественного наследования). Пихал их по поводу и без везде, было удобно и понятно, код переиспользуется, все классно
    Ответить

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

Я, guest, находясь в здравом уме и твердой памяти, торжественно заявляю:

    А не использовать ли нам bbcode?


    8