Комментарии 30
Пули нет, но есть нюанс. :) А именно: если стараться не писать сложных программ в принципе, разбивать сложную программу на несколько простых и более-менее независимых модулей/серверов/сервисов/программ, то выясняется что для таких простых программ ООП это зачастую overkill.
Иными словами, если возникает потребность в ООП (внимание, именно осознанная потребность!), то это зачастую является признаком того, что программа слишком сложная и нужно ещё поработать над архитектурой и её упростить.
P.S. Ой... чичас меня будут избивать ножками...
Иными словами, если возникает потребность в ООП (внимание, именно осознанная потребность!), то это зачастую является признаком того, что программа слишком сложная и нужно ещё поработать над архитектурой и её упростить.
P.S. Ой... чичас меня будут избивать ножками...
Есть еще такая вещь как сопровождение кода (особенно актуальная в "больших" проектах). Так вот, на мой взгляд, ООП как раз позволяет сделать код более читабельным и соответственно более понятным окружающим (заинтересованным) людям. Ну а в плане построения прозрачной архитектуры, тут конечно все во многом зависит от архитекторов ;)
Автор, приведите пример проекта, который требует на стадии проектирования потенциально более десяти тысяч человекочасов, и где при современном развитии технологии и платформ принято решение в пользу процедурного программирования?
"Все" не могут ошибаться, да? :)
Вы считаете, что я пытаюсь склонить людей в сторону процедурного программирования? Тем более, по-моему я написал о связи укрупнения программ и ООП.
Так же я очень не люблю человекочасы, они ведут к человекомесяцам.
Так же я очень не люблю человекочасы, они ведут к человекомесяцам.
Продолжим.
Вот тут сбоку подсказывают, что движок 3 кваки был написан на СИ (без плюсов). Сплошные структы и прочие прелести. И один модуль работы со сплайнами на C++. Думаю, вполне себе пример, да?
Вот тут сбоку подсказывают, что движок 3 кваки был написан на СИ (без плюсов). Сплошные структы и прочие прелести. И один модуль работы со сплайнами на C++. Думаю, вполне себе пример, да?
Могу выложить движок Кваки. Кстати, Вы правы, я тоже на это как-то обратил внимание. Кода, к слову, в проекте не шибко много.
ООП определяет скорее какие сущности в программе вы выделяете и как с ними работаете. К языку он прямого отношения не имеет. ООП-программы можно писать и на Си, и на ассемблере, просто требуется придерживаться ОО-мышления. Ну и придется некоторые вещи делать "руками" и не так просто как на С++. (см. Буча http://khpi-iip.mipk.kharkiv.edu/library/case/buch/ch02.html)
Так что я подозреваю, что движок Кваки структурирован довольно хорошо в какую-то систему объектов и не является просто месивом кода, структур и функций...
Так что я подозреваю, что движок Кваки структурирован довольно хорошо в какую-то систему объектов и не является просто месивом кода, структур и функций...
Важно избежать фанатичной помешанности на одной парадигме.
Не менее важно, наверное, также избежать "фанатичной помешанности" на смешивании парадигм :) мне вот тут подумалось - может быть золотая середина как раз придерживаться определенной (наиболее удобной) парадигмы в рамках отдельных модулей большого проекта...
Фанатизм вообще вредно ;)
солидарен.
но иногда использование тех или иных парадигм диктуются инструментарием :)
я например слабо представляю объектный подход в T-SQL...
но иногда использование тех или иных парадигм диктуются инструментарием :)
я например слабо представляю объектный подход в T-SQL...
//упс. не дописал, запостилось само :(
и процедурный в Java/C# :)
имхо, спор о парадигмах скорее сводится к выбору инструментов. есть не так уж и много языков, которые позволяют писать и так, и эдак, и еще вот-так (кивок в сторону PHP), остальные ставят разработчика в жесткие рамки и говорят - "не нравится — свободен" :)
и процедурный в Java/C# :)
имхо, спор о парадигмах скорее сводится к выбору инструментов. есть не так уж и много языков, которые позволяют писать и так, и эдак, и еще вот-так (кивок в сторону PHP), остальные ставят разработчика в жесткие рамки и говорят - "не нравится — свободен" :)
Инструмент конечно диктует ;)
Но никакой инструмент не заставит любителя какого-либо подхода изменить свой подход. Можно на языке, состоящем сплошь из объектов писать так, как будто работаешь с процедурами.
Но никакой инструмент не заставит любителя какого-либо подхода изменить свой подход. Можно на языке, состоящем сплошь из объектов писать так, как будто работаешь с процедурами.
не скажите, не скажите...
- процедурные языки ну никак не позволят вам удобоваримо "эмулировать" объекты :)
- хорошие IDE (Idea, VisualStudio+Resharper) очень быстро вызывают привыкание, а со временем еще и изменяют образ мышления. как только начинаешь привыкать отделять мух от котлет... :) не скажу что это всегда хорошо, но заставлят меняться... заставляют...
блин! пример вспомнил!
эволюцию можно заметить в ruFlash, с выходом ASDT и FDT все резко возлюбили AS2 и ООП, хотя очень многие до этого отлично жили с нагрмождением function :)
эволюцию можно заметить в ruFlash, с выходом ASDT и FDT все резко возлюбили AS2 и ООП, хотя очень многие до этого отлично жили с нагрмождением function :)
Процедурные - да. Но я говорю скорее о восприятии программы, чем о конкретной реализации языка. Кто-то воспринимает как функции, кто-то - как объекты, кто-то - ещё как-то, благо парадигм и способов хватает. А от восприятия уже и появляется соответствующее поведение и написание.
По поводу примера - что ж, если люди убедились, что им полезнее и удобнее ООП, то я за них рад. А если это только дань моде - значит пройдёт.
Я сам долго писал, используя процедурный подход. А потом вдруг понял, что его мне уже мало. И стал использовать ООП, что, прочем, не мешает мне писать функции в отдельных случаях.
По поводу примера - что ж, если люди убедились, что им полезнее и удобнее ООП, то я за них рад. А если это только дань моде - значит пройдёт.
Я сам долго писал, используя процедурный подход. А потом вдруг понял, что его мне уже мало. И стал использовать ООП, что, прочем, не мешает мне писать функции в отдельных случаях.
Что-то к концу статьи со всеми этими аббревиатурами вообще темный лес начался.
А про серебрянные пули это вообще Брукс сказал.
А про серебрянные пули это вообще Брукс сказал.
TDD это уже позапрошлый месяц. модные пацаны используют BDD ;)
Мне кажется, что автор путает функциональную и процедурную парадигмы программирования. А между тем, это разные вещи. Функциональные языки - это Lisp, Standard ML, Haskell, OCaml... Противопоставлять их ООП, как минумум, сложно. А вот процедурную и ОО парадигмы вполне можно в определенных пределах. (Я лично сторонник ООП)
Почитайте: http://ru.wikipedia.org/wiki/Парадигма_п…
Почитайте: http://ru.wikipedia.org/wiki/Парадигма_п…
Насчёт пули Брукс оставил хорошие подсказки.
"Наиболее радикальное возможное решение при создании программ - вообще не создавать их."
"Радикально улучшить устойчивость программных продуктов и производительность труда при их создании можно, лишь поднявшись на один уровень и изготавливая программы из модулей или объектов."
Сколько проектов, в разработке которых вы принимали участие, действительно оказались востребованными и живут и развиваются до сих пор? У меня такие "проекты" это в основном наращивание существующей системы разработанной довольно давно. И тем не менее, были "фичи", о которых менеджмент считал "мы с этой фичей всех порвём", а оказывалось что это нужно немногим... Так что проще всё-таки больше думать о том, что стоит делать вообще, и как это сделать более целесообразно, а не о технологиях "как это сделать быстрее" (длинный список аббревиатур которые мы все знаем)...
"Наиболее радикальное возможное решение при создании программ - вообще не создавать их."
"Радикально улучшить устойчивость программных продуктов и производительность труда при их создании можно, лишь поднявшись на один уровень и изготавливая программы из модулей или объектов."
Сколько проектов, в разработке которых вы принимали участие, действительно оказались востребованными и живут и развиваются до сих пор? У меня такие "проекты" это в основном наращивание существующей системы разработанной довольно давно. И тем не менее, были "фичи", о которых менеджмент считал "мы с этой фичей всех порвём", а оказывалось что это нужно немногим... Так что проще всё-таки больше думать о том, что стоит делать вообще, и как это сделать более целесообразно, а не о технологиях "как это сделать быстрее" (длинный список аббревиатур которые мы все знаем)...
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
ООП и всё такое: Тихо, про себя