lucker пишет:Привер чего? Воняющего кода? Почитайте Мартина Фаулера "Рефакторинг", если еще этого не сделали, там очень красочно описано большинство запахов, и даже даны рецепты их устранения.
Ну ок. Вы упоминали про if-else-case, пусть будет он. Фаулер предлагает для уменьшения количества подобных конструкций использовать полиморфизм, однако такое решение не покрывает все возможные варианты их использования. Например, вы ну никак не закодируете через полиморфизм таблицу переходов конечного автомата. Всё, что вы можете сказать, когда видете множество одинаковых switch'ей или if-else'ов, так это то, что их можно вынести в одну какую-то процедуру, чтобы в дальнейшем можно было внести изменения только в неё. Как видите, пока что никакого ООП. Дальше вы смотрите, сводятся ли все условия к проверке одного или нескольких фиксированных критериев. Если это так, то можно воспользоваться паттерном диспетчеризации. Процедурным паттерном, который существовал за долго до появления первых ОО-языков, и который гораздо важнее для понимая, чем любой полиморфизм. Дальше вы смотрите, по скольки параметрам проходит диспетчеризация. И вот тууут, если диспетчеризация проходит только по одному параметру, вы вспоминаете, что у вас в языке уже есть механизм для этого, и называется он полиморфизм. В конце вы ещё проверяете, можете ли привести все необходимые типы к единому интерфейсу и добавить этим типам нужный метод. Прокатило? Круто, вы использовали ООП для решения своей проблемы. Именно использовали его, оно сыграло положительную роль. Если же вы не прошли в своей голове всю эту логическую цепочку, или если не выполнилось хотя бы одно из указанный условий (диспетчеризация по нескольким параметрам, диспетчеризация не по типу, а по какому-то другому критерию, etc), то вы попадаете в просак, и начинаете бороться с языком, изобретая паттерны двойной диспетчеризации, стратегии и т.д.
Таким образом, необходимо в первую очередь знать наиболее общие и фундаментальные способы решения проблем, а затем уже отыскивать подходящие средства в своём конкретном языке программирования.
lucker пишет:Я понимаю к чему вы клоните. Да, Java язык со статической типизацией, и тип объекта нельзя расширить не имея доступ к исходному коду. Да, у этого есть плюсы и есть минусы. И нет, это не нарушаает принцип полиморфизма, и если нужно полиморфно работать со списками, файлами и строками то есть множество приемов, как это сделать.
Хорошо, скажу по-другому: несмотря на то, что полиморфизм объявлен одним из основополагающих принципов ООП (и Java, в частности), его не только несправедливо мало используют в самом языке, но и крайне редко он встречается и в прикладных библиотеках: строка - отдельный класс, файл - отдельный класс, консольный поток символов - отдельный, список - отдельный, поток токенов - тоже отдельный. Придумали даже спеицальный итератор, чтобы бегать по структурным данным, но вот невезуха - тоже не прижился. Ну и какой смысл после этого хорошо знать ООП, если применить его негде?
Так вы говорите? Или всё таки "пойду налью в чашку кофе"? Если учитывать, что это не сами объекты совершают действие (мы наливаем кофе, а не кофе само наливается), то приходим к правилам русского, английского, да и любого из европейских языков - дополнение ставится после сказуемого, и никак иначе. 
