Pull to refresh

Comments 30

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

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

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

Так же я очень не люблю человекочасы, они ведут к человекомесяцам.
Продолжим.
Вот тут сбоку подсказывают, что движок 3 кваки был написан на СИ (без плюсов). Сплошные структы и прочие прелести. И один модуль работы со сплайнами на C++. Думаю, вполне себе пример, да?
Могу выложить движок Кваки. Кстати, Вы правы, я тоже на это как-то обратил внимание. Кода, к слову, в проекте не шибко много.
UFO just landed and posted this here
Важно избежать фанатичной помешанности на одной парадигме.

Не менее важно, наверное, также избежать "фанатичной помешанности" на смешивании парадигм :) мне вот тут подумалось - может быть золотая середина как раз придерживаться определенной (наиболее удобной) парадигмы в рамках отдельных модулей большого проекта...
Фанатизм вообще вредно ;)
Т.е. вреден, естественно.
солидарен.
но иногда использование тех или иных парадигм диктуются инструментарием :)
я например слабо представляю объектный подход в 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/Парадигма_п…
Я по-моему не писал слово «функциональная» ;)
>>Я стараюсь не спорить о преимуществах / недостатках ООП или **функционального подхода**, безразлично где.

Не оно?
Ошибся. Поправлю ;) Дальше по тексту функционального подхода нет.
UFO just landed and posted this here
Sign up to leave a comment.

Articles