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

    +77

    1. 1
    2. 2
    Superclass s = new Subclass();
    ((Subclass)s).useSubclassMethod();

    Чудеса полиморфизма.

    Запостил: thePooh, 11 Апреля 2012

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

    • наглядная демонстрация того, как пхпшники не могут в ООП.
      Ответить
      • Вопрос в том нах оно надо? Лишние косяки типа а если будет вызван метод который не определен в Subclass
        в пхп такое можно реализовать с помощью фабрики классов.
        Ответить
        • Навеяло: "мы представим единую фабрику фабрик фабрик"
          отсюда http://habrahabr.ru/post/141477/
          Ответить
          • Это скорее тонкий наезд на ФП
            Ответить
            • а при чём тут ФП вообще?
              Ответить
              • ФП = Фабричное Программирование :)
                Ответить
              • Статья является скорее наездом на высокие абстракии (паттерны метапаттернов), чем на фреймворки, которые просто набор процедур, и которые и есть просто молотки.
                Ответить
                • статья (а точнее, ее английский оригинал) более чем является наездом на усложнение разработки, благодаря высоким абстракциям, вместо ее упрощения.
                  Ответить
                  • Короче, статья про KISS, а не про фреймворки.
                    Ответить
                    • нет, именно про фреймворки, шаблоны и иже.

                      скажем, нам надо написать простую страницу на пхп:
                      1. мы пишем на "голом" пхп страницу.
                      2. используя какой-либо пхп-фреймворк, который, конечно же, без шаблона MVC не обходится - надо создать, как минимум, контроллер, вьюху и модель - уже три файла как минимум. Причем, если ты не знаешь принципов MVC и особенностей конкретного фреймворка - это три никак не связанных (мало какая IDE по ctrl+click перейдет куда надо, а то и ваще будет ругаться, что переменные взяты с потолка) файла

                      в общем, статья о том, что фреймворки ЗАСТАВЛЯЮТ ради иных выгод (слабая связанность, тестируемость и т.д.) писать больше и сложнее.

                      особенно яркая ситуация в Java - чтобы создать страницу в некоем фреймворке (не буду называть), нужно:
                      1. написать html или jsp страницу (особенно забавно, что нужно использовать библиотеку тегов этого фреймворка)
                      2. написать как минимум один java класс, по собственным соглашениям (от чего наследуется или какой интерфейс реализует, как называются методы и с какой сигнатурой)
                      3. связать это все еще в одном xml файле
                      4. убедиться, что эти три файла согласованы по всем статьям, а то в лучшем случае получим ошибку выполнения, в худшем - будем долго задаваться эмоциональным вопросом "какого хуя не работает, все же правильно!"
                      при этом налицо избыточность как минимум xml-описатора.

                      Вот про что статья.
                      я, как и большинство, готов смириться с этой избыточностью в пользу поддерживаемости приложения
                      Ответить
                      • Там в комментах прозвучал типичный Ява-вопрос про логгеры: "а что если я захочу перенаправить вывод в файл?" - на который обычно Ява-хардкор-программист не задумываясь согласится с тем, что написать или использовать чужой логгер-фреймворк лучше, чем при вызове программы перенаправить вывод в файл через ">", например. Ну и т.п.
                        Я это говорю к тому, что это даже не проблема существования фреймворков как таковых, а в унылом проектировании, которое не представляет как можно использовать две программы вместе, и поэтому все программы включают в себя друг друга более чем полностью.
                        Ответить
                        • 1. перенаправить вывод в файл через ">" - это совсем другой подход
                          2. спустя какое-то время программирования на джаве формируется определенный поведенческий шаблон, называемый "ООП головного мозга", когда при любой задаче первый инстинкт - нагородить кучу объектов и паттернов, а иной подход кажется противоестественным и неудобным.

                          именно поэтому надо периодически бить себя по рукам и затылку, и для общего развития изучать языки с другим подходом - например, функциональные и т.д.
                          Ответить
        • > а если будет вызван метод который не определен в Subclass
          это насколько должна быть расшатана психика, чтобы вызывать у суперкласса метод подкласса, которого, вполне логично, никак у суперкласса оказаться не может (только если речь не идет о замещениях или реализациях, это совсем другая тема).

          Применительно к сабжу - непонятно, чего добивался автор.
          если ему нужен суперкласс - то неважно, какой потомок его представляет, он представляет только своего родителя.
          если же он знает про потомка, то почему бы этот s и не обьявить как Subclass.

          Такое могло родиться в том случае, если есть несколько подклассов этого суперкласса, и у всех этот метод есть, а у родителя - нет. Вот тут и видно, что прогер не понимает суть ООП - ведь в таком случае правильно было бы либо обьявить этот метод или в самом Superclass, или родить от него свой субкласс (назовем для пример SubSuperclass), в котором этот метод useSubclassMethod (с некоей реализацией, возможно пустой, либо абстрактный метод) определен, а уже от него порождать всякие там Subclass (и в обьявлении указывать именно SubSuperclass).
          замечание одно - от конкретного суперкласса некоторые практики не рекомендуют наследовать абстрактные классы.
          Ответить
    • Полагаю, что благодаря http://www.rusonyx.ru/jelastic/ яваговнокода только прибавится...
      Ответить

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