ООП и всё такое: Тихо, про себя

    Я стараюсь не спорить о преимуществах / недостатках ООП или процедурного подхода, безразлично где.

    Хочешь — рассматривай программу как множество функций. Хочешь — как множество объектов. Хочешь — вообще заморочься на аспектах. А ещё есть товарищ Шалыто и его конечные автоматы. Дело-то хозяйское.

    Важно понимать, что парадигмы возникали не просто так. Появление ООП вызвано, не в последнюю очередь, укрупнением программ и усложнением их архитектуры. Сейчас же часто говорят о АОП, которое выносит сквозную функциональность в отдельную сущность, что может сильно экономить усилия человека.

    Также, очень важно чётко определить цели твоей программы — от этого зависит, какая парадигма подойдёт. Если тебя волнует расширяемость — что ж, видимо тебе придётся познакомиться с ООП. Если скорость — то процедурный подход. Важно избежать фанатичной помешанности на одной парадигме.

    После определения, в любом случае, не стоит забывать про рефакторинг (тут выскакивает Мартин Фаулер, и кричит — Нюхай свой код! Определяй запахи!). Больше всего рефакторинга в ООП, но и функции тоже можно рефакторить.

    Дальше — больше: вспоминаются паттерны, которые представляют собой шаблонные методы обхода насущных проблем языка и решения архитектурных заморочек. Где паттерны — там GOF и Фаулер с POEAA. Затем всплывает TDD, с его написанием тестов перед написанием кода. Дальше — ещё больше, там будут горы непонятных аббревиатур и леса методологий.

    На подобные темы писалось, пишется и будет писаться много.

    Но нет серебряной пули.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое