Теоретические проблемы ОО
29.04.2006
|
IT
 |
Здравствуйте, Maxim S. Shatskih, Вы писали:
Честно говоря, надоели уже до чёртиков все эти разговоры про недостатки ООП. Я предлагаю прекратить подобные инсинуации и начать проще относиться к жизни в целом и к ООП в частности. Нужно всего-то лишь перестать думать об ООП как о панацее и/или серебряной пуле и всё сразу станет на свои места.
Лично я уже давно отношусь к ООП просто как к набору удобных, хорошо зарекомендовавших себя дизайн паттернов, которые экономят мне кучу времени. Как-то после первого года работы на C++, мой шеф заставил меня писать обратно на чистом C, якобы в целях какой-то там совместимости. Помню, ломка у меня тогда началась с первых же строк кода. И что забавно после завершения работы я обнаружил практически у всех моих методов наличие первого параметра с характерным названием this. Т.е. что я сделал? Правильно, использовал один из паттернов, традиционно применяемых в ООП. А виндузовые handlers ничего не напоминают? Ну, например, ассоциации с паттерном инкапсуляция не напрашивается? А polymorphic behavior никто с помощью указателей на функции в C не делал? Я делал, очень удобно было реализовывать обработчики всевозможных событий, хотя даже само слово событие вошло в мой лексикон гораздо позже.
И что, после 15 лет все эти возможности куда-то испарились или стали невостребованными? Я думаю, что нет. Просто отдельные индивидуумы, выучив определение трёх основных составляющих ООП начинают пихать его во все нужные и ненужные места и потом искренне удивляются, почему это в ООП плохи дела с “параллельным программированием” и злобные основоположники парадигмы забыли решить “вопрос операций сразу на большим количеством похожих элементов данных”.
А может просто хватит заниматься фигнёй?
В общем, вывод может быть такой. У ООП есть только один недостаток – возможность использовать его не по назначению.
Но такие недостатки можно найти практически у любого предмета. Например, большой недостаток молотка заключается в том, что им очень больно попадать по пальцам, проблема лобзика в том, что им очень неудобно валить Беловежскую пущу, а к несомненным недостаткам выхлопной трубы можно отнести явное неудобство через неё регулировать клапана двигателя практически любого современного автомобиля.
И даже венец творения природы человек не лишён подобных недостатков. Видишь ли, не через любое отверстие в нём можно качественно удалить ему гланды
ЗЫ. Руки прочь от ООП!
Честно говоря, надоели уже до чёртиков все эти разговоры про недостатки ООП. Я предлагаю прекратить подобные инсинуации и начать проще относиться к жизни в целом и к ООП в частности. Нужно всего-то лишь перестать думать об ООП как о панацее и/или серебряной пуле и всё сразу станет на свои места.
Лично я уже давно отношусь к ООП просто как к набору удобных, хорошо зарекомендовавших себя дизайн паттернов, которые экономят мне кучу времени. Как-то после первого года работы на C++, мой шеф заставил меня писать обратно на чистом C, якобы в целях какой-то там совместимости. Помню, ломка у меня тогда началась с первых же строк кода. И что забавно после завершения работы я обнаружил практически у всех моих методов наличие первого параметра с характерным названием this. Т.е. что я сделал? Правильно, использовал один из паттернов, традиционно применяемых в ООП. А виндузовые handlers ничего не напоминают? Ну, например, ассоциации с паттерном инкапсуляция не напрашивается? А polymorphic behavior никто с помощью указателей на функции в C не делал? Я делал, очень удобно было реализовывать обработчики всевозможных событий, хотя даже само слово событие вошло в мой лексикон гораздо позже.
И что, после 15 лет все эти возможности куда-то испарились или стали невостребованными? Я думаю, что нет. Просто отдельные индивидуумы, выучив определение трёх основных составляющих ООП начинают пихать его во все нужные и ненужные места и потом искренне удивляются, почему это в ООП плохи дела с “параллельным программированием” и злобные основоположники парадигмы забыли решить “вопрос операций сразу на большим количеством похожих элементов данных”.
А может просто хватит заниматься фигнёй?
В общем, вывод может быть такой. У ООП есть только один недостаток – возможность использовать его не по назначению.
Но такие недостатки можно найти практически у любого предмета. Например, большой недостаток молотка заключается в том, что им очень больно попадать по пальцам, проблема лобзика в том, что им очень неудобно валить Беловежскую пущу, а к несомненным недостаткам выхлопной трубы можно отнести явное неудобство через неё регулировать клапана двигателя практически любого современного автомобиля.
И даже венец творения природы человек не лишён подобных недостатков. Видишь ли, не через любое отверстие в нём можно качественно удалить ему гланды
ЗЫ. Руки прочь от ООП!
... << RSDN@Home 1.2.0 alpha rev. 0>>
| 29.04.2006 6 комментариев |
Есть такое страшное слово — "парадигма". Достаточно нечто обозвать парадигмой, как вокруг этого нечто образуется своя толпа фанатов и фанатиков, с пеной у рта начинающих доказывать состоятельность и всеобъемность этой парадигмы другой толпе фанатов и фанатиков.
ООП парадигма... Java вон, толкает
Или из недавнего: Языково-ориентированное программирование: следующая парадигма
Сейчас, боюсь, силами С# начнут проталкивать функциональную парадигму.
Силами какой-нибудь Singularity — парадигму, что "все есть объект или процесс".
IT>Честно говоря, надоели уже до чёртиков все эти разговоры про недостатки ООП.
о боже, ты ли это говоришь?
На самом деле ООП не решает некоторые задачи, и его возможности неплохо бы расширить.
Д>о боже, ты ли это говоришь?
Я знал что ты здесь появишься и обязательно отметишься
Д>На самом деле ООП не решает некоторые задачи, и его возможности неплохо бы расширить.
ООП хорошо решает то, что решает хорошо. Речь как раз о том стоит ли пытаться впихнуть в ООП всё, что способен сочинить около объектного воспалённый мозг разработчика.
IT>ООП хорошо решает то, что решает хорошо. Речь как раз о том стоит ли пытаться впихнуть в ООП всё, что способен сочинить около объектного воспалённый мозг разработчика.
Если такая задача стоит перед разработчиком — возможно, стоит.
Кстати, чего лично мне очень не хватает — это удобной поддержки Inversion of control/системы сервисов на уровне языка. Кому-нибудь еще это нужно, интересно?
Д>Если такая задача стоит перед разработчиком — возможно, стоит.
А может, просто ввести какую-нибудь ортогональную концепцию?
S>А может, просто ввести какую-нибудь ортогональную концепцию?
совсем ортогональную не получится. Скорее, что-то Х-образное