- 1
- 2
Superclass s = new Subclass();
((Subclass)s).useSubclassMethod();-
Java / Говнокод #9926
+77
Чудеса полиморфизма.
Запостил:
thePooh,
11 Апреля 2012
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
в пхп такое можно реализовать с помощью фабрики классов.
отсюда http://habrahabr.ru/post/141477/
скажем, нам надо написать простую страницу на пхп:
1. мы пишем на "голом" пхп страницу.
2. используя какой-либо пхп-фреймворк, который, конечно же, без шаблона MVC не обходится - надо создать, как минимум, контроллер, вьюху и модель - уже три файла как минимум. Причем, если ты не знаешь принципов MVC и особенностей конкретного фреймворка - это три никак не связанных (мало какая IDE по ctrl+click перейдет куда надо, а то и ваще будет ругаться, что переменные взяты с потолка) файла
в общем, статья о том, что фреймворки ЗАСТАВЛЯЮТ ради иных выгод (слабая связанность, тестируемость и т.д.) писать больше и сложнее.
особенно яркая ситуация в Java - чтобы создать страницу в некоем фреймворке (не буду называть), нужно:
1. написать html или jsp страницу (особенно забавно, что нужно использовать библиотеку тегов этого фреймворка)
2. написать как минимум один java класс, по собственным соглашениям (от чего наследуется или какой интерфейс реализует, как называются методы и с какой сигнатурой)
3. связать это все еще в одном xml файле
4. убедиться, что эти три файла согласованы по всем статьям, а то в лучшем случае получим ошибку выполнения, в худшем - будем долго задаваться эмоциональным вопросом "какого хуя не работает, все же правильно!"
при этом налицо избыточность как минимум xml-описатора.
Вот про что статья.
я, как и большинство, готов смириться с этой избыточностью в пользу поддерживаемости приложения
Я это говорю к тому, что это даже не проблема существования фреймворков как таковых, а в унылом проектировании, которое не представляет как можно использовать две программы вместе, и поэтому все программы включают в себя друг друга более чем полностью.
2. спустя какое-то время программирования на джаве формируется определенный поведенческий шаблон, называемый "ООП головного мозга", когда при любой задаче первый инстинкт - нагородить кучу объектов и паттернов, а иной подход кажется противоестественным и неудобным.
именно поэтому надо периодически бить себя по рукам и затылку, и для общего развития изучать языки с другим подходом - например, функциональные и т.д.
это насколько должна быть расшатана психика, чтобы вызывать у суперкласса метод подкласса, которого, вполне логично, никак у суперкласса оказаться не может (только если речь не идет о замещениях или реализациях, это совсем другая тема).
Применительно к сабжу - непонятно, чего добивался автор.
если ему нужен суперкласс - то неважно, какой потомок его представляет, он представляет только своего родителя.
если же он знает про потомка, то почему бы этот s и не обьявить как Subclass.
Такое могло родиться в том случае, если есть несколько подклассов этого суперкласса, и у всех этот метод есть, а у родителя - нет. Вот тут и видно, что прогер не понимает суть ООП - ведь в таком случае правильно было бы либо обьявить этот метод или в самом Superclass, или родить от него свой субкласс (назовем для пример SubSuperclass), в котором этот метод useSubclassMethod (с некоей реализацией, возможно пустой, либо абстрактный метод) определен, а уже от него порождать всякие там Subclass (и в обьявлении указывать именно SubSuperclass).
замечание одно - от конкретного суперкласса некоторые практики не рекомендуют наследовать абстрактные классы.