Как стать автором
Обновить

Комментарии 30

Пули нет, но есть нюанс. :) А именно: если стараться не писать сложных программ в принципе, разбивать сложную программу на несколько простых и более-менее независимых модулей/серверов/сервисов/программ, то выясняется что для таких простых программ ООП это зачастую overkill.

Иными словами, если возникает потребность в ООП (внимание, именно осознанная потребность!), то это зачастую является признаком того, что программа слишком сложная и нужно ещё поработать над архитектурой и её упростить.

P.S. Ой... чичас меня будут избивать ножками...
Есть еще такая вещь как сопровождение кода (особенно актуальная в "больших" проектах). Так вот, на мой взгляд, ООП как раз позволяет сделать код более читабельным и соответственно более понятным окружающим (заинтересованным) людям. Ну а в плане построения прозрачной архитектуры, тут конечно все во многом зависит от архитекторов ;)
Ага, если много разработчиков - тут ООП как раз очень хорош. Для того - public и есть.
public вестимо не совсем для того есть :) хотя может я не совсем понял Вашу мысль
отдаёшь public, и остальные разработчики не мучаются - просто пользуют интерфейс. Что то ещё удобного?
разбираться с архитектурой удобно :) строить эту самую архитектуру удобно, рефакторить, если хотите, тоже удобно, а с этих точек зрения public также хорошо как и private ;)
Автор, приведите пример проекта, который требует на стадии проектирования потенциально более десяти тысяч человекочасов, и где при современном развитии технологии и платформ принято решение в пользу процедурного программирования?
"Все" не могут ошибаться, да? :)
Вы считаете, что я пытаюсь склонить людей в сторону процедурного программирования? Тем более, по-моему я написал о связи укрупнения программ и ООП.

Так же я очень не люблю человекочасы, они ведут к человекомесяцам.
Продолжим.
Вот тут сбоку подсказывают, что движок 3 кваки был написан на СИ (без плюсов). Сплошные структы и прочие прелести. И один модуль работы со сплайнами на C++. Думаю, вполне себе пример, да?
Могу выложить движок Кваки. Кстати, Вы правы, я тоже на это как-то обратил внимание. Кода, к слову, в проекте не шибко много.
ООП определяет скорее какие сущности в программе вы выделяете и как с ними работаете. К языку он прямого отношения не имеет. ООП-программы можно писать и на Си, и на ассемблере, просто требуется придерживаться ОО-мышления. Ну и придется некоторые вещи делать "руками" и не так просто как на С++. (см. Буча — http://khpi-iip.mipk.kharkiv.edu/library/case/buch/ch02.html)

Так что я подозреваю, что движок Кваки структурирован довольно хорошо в какую-то систему объектов и не является просто месивом кода, структур и функций...
Важно избежать фанатичной помешанности на одной парадигме.

Не менее важно, наверное, также избежать "фанатичной помешанности" на смешивании парадигм :) мне вот тут подумалось - может быть золотая середина как раз придерживаться определенной (наиболее удобной) парадигмы в рамках отдельных модулей большого проекта...
Фанатизм вообще вредно ;)
Т.е. вреден, естественно.
солидарен.
но иногда использование тех или иных парадигм диктуются инструментарием :)
я например слабо представляю объектный подход в T-SQL...
//упс. не дописал, запостилось само :(
и процедурный в Java/C# :)

имхо, спор о парадигмах скорее сводится к выбору инструментов. есть не так уж и много языков, которые позволяют писать и так, и эдак, и еще вот-так (кивок в сторону PHP), остальные ставят разработчика в жесткие рамки и говорят - "не нравится — свободен" :)
Инструмент конечно диктует ;)
Но никакой инструмент не заставит любителя какого-либо подхода изменить свой подход. Можно на языке, состоящем сплошь из объектов писать так, как будто работаешь с процедурами.
не скажите, не скажите...

  1. процедурные языки ну никак не позволят вам удобоваримо "эмулировать" объекты :)

  2. хорошие IDE (Idea, VisualStudio+Resharper) очень быстро вызывают привыкание, а со временем еще и изменяют образ мышления. как только начинаешь привыкать отделять мух от котлет... :) не скажу что это всегда хорошо, но заставлят меняться... заставляют...

блин! пример вспомнил!
эволюцию можно заметить в ruFlash, с выходом ASDT и FDT все резко возлюбили AS2 и ООП, хотя очень многие до этого отлично жили с нагрмождением function :)
Процедурные - да. Но я говорю скорее о восприятии программы, чем о конкретной реализации языка. Кто-то воспринимает как функции, кто-то - как объекты, кто-то - ещё как-то, благо парадигм и способов хватает. А от восприятия уже и появляется соответствующее поведение и написание.

По поводу примера - что ж, если люди убедились, что им полезнее и удобнее ООП, то я за них рад. А если это только дань моде - значит пройдёт.

Я сам долго писал, используя процедурный подход. А потом вдруг понял, что его мне уже мало. И стал использовать ООП, что, прочем, не мешает мне писать функции в отдельных случаях.
Что-то к концу статьи со всеми этими аббревиатурами вообще темный лес начался.

А про серебрянные пули это вообще Брукс сказал.
В нашем деле без леса никак ;)
Да, это был точно Брукс. А вобще про серебрянные пули говорят все кому не лень ;)
TDD это уже позапрошлый месяц. модные пацаны используют BDD ;)
Моду оставим модным.
Спасибо, почитаю.
Мне кажется, что автор путает функциональную и процедурную парадигмы программирования. А между тем, это разные вещи. Функциональные языки - это Lisp, Standard ML, Haskell, OCaml... Противопоставлять их ООП, как минумум, сложно. А вот процедурную и ОО парадигмы вполне можно в определенных пределах. (Я лично сторонник ООП)

Почитайте: http://ru.wikipedia.org/wiki/Парадигма_п…
Я по-моему не писал слово «функциональная» ;)
>>Я стараюсь не спорить о преимуществах / недостатках ООП или **функционального подхода**, безразлично где.

Не оно?
Ошибся. Поправлю ;) Дальше по тексту функционального подхода нет.
Насчёт пули — Брукс оставил хорошие подсказки.

"Наиболее радикальное возможное решение при создании программ - вообще не создавать их."

"Радикально улучшить устойчивость программных продуктов и производительность труда при их создании можно, лишь поднявшись на один уровень и изготавливая программы из модулей или объектов."

Сколько проектов, в разработке которых вы принимали участие, действительно оказались востребованными и живут и развиваются до сих пор? У меня такие "проекты" — это в основном наращивание существующей системы разработанной довольно давно. И тем не менее, были "фичи", о которых менеджмент считал "мы с этой фичей всех порвём", а оказывалось что это нужно немногим... Так что проще всё-таки больше думать о том, что стоит делать вообще, и как это сделать более целесообразно, а не о технологиях "как это сделать быстрее" (длинный список аббревиатур которые мы все знаем)...
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.