Не учите паттерны, учите концепции

Добрый день (или вечер, или утро, в зависимости от того, когда выйдет этот пост).

Я хочу высказаться об элитарной части программирования и донести, в общем-то, очевидную мысль до начинающих в back-end (и не только) разработке, попутно используя попытку начать писать на Хабре.

Итак


Любой программист с хоть немного хорошим вкусом, начавший программировать по своей воле, после понимания основ языка и написания первых проектов, будет задаваться вопросом не «как сделать что-то», а «как сделать что-то правильно» и «какие тут есть стандарты красоты».

Эти, безусловно верные, вопросы, рано или поздно приведут его к непонятным названиям «Абстрактная фабрика», «Синглтон», «Медиатор» и не менее понятным аббревиатурам SOLID, GRASP.

Обратите внимание, что я не привел в пример ООП, MVC, ORM — это концепции с весьма конкретным смыслом и областью применения, имеющие минимальный уровень абстракции.

ООП говорит: «чувак, я нашел наглядный и понятный способ представления программ».
MVC говорит: «чел, будет лучше, если ты разделишь код, а правила разделения под катом».
ORM говорит: «псс, парень, я тут нашел способ помирить две разные идеологии — ООП и БД».
Тут все понятно.

Я говорю про вещи, которые предполагают максимальный уровень абстракции. Пример:
«Посредник»:
чел, если у тебя есть много разных объектов, сделай один центральный, к нему подключи все остальное.
Программист просто странно посмотрит в его сторону, если он общительный, скажет «спасибо, кэп!», а за глаза будет называть не иначе как «капитан очевидность».

То же самое про другие паттерны:
«Фабрика»:
чел, а ты знал, что можно конструировать объекты посредством другого класса?
«Data mapper»:
а почему бы тебе не использовать дополнительный слой абстракции для сохранения данных?
«Наблюдатель»:
парень, а давай намутим интерфейсов?
«Стратегия»:
ты знаешь что такое полиморфизм?
И особенно SOLID:
S (single responsibility):
один модуль должен выполнять только одну задачу, не забывай об этом!
I (interface segregation):
для разных операций используй разные интерфейсы!
Ну и так далее.

Я веду к тому, что основная сфера применения паттернов вовсе не в приучении к хорошему коду. Паттерны нужны для обсуждения уже написанной кем-то программы, для формализации хорошего кода. Чтобы можно было сказать («а это чего за класс?» — «а, это часть посредника»). Но не для того, чтобы сверять свою писанину с uml-ками паттернов в судорожном приступе «ааа, какой же паттерн применить в этом случае?».

Программист, хорошо владеющий какой-то концепцией (например, из приведенных выше), сам будет писать код, используя best practices, даже если он не слышал о них ни слова. А те самые best practices нужны, чтобы формализовать отношение его тимлида к его коду — и квинтэссенцией тут является, конечно же, GRASP.

Что я хотел бы сказать начинающим программистам:

  1. учите концепции, а не паттерны. Концепции реально важны.
  2. если вы вдруг опомнились, что не знаете паттернов, не надо паниковать. Это будет иметь значение только для рекрутера, но никак не для вашего кода и хорошего стиля.

Что я хотел бы сказать гуру Хабра:

  1. Я могу быть неправ. Серьезно.
  2. Я понимаю, мысль банальна. Но, тем не менее, почему-то я часто встречаю подобный подход у начинающих.
  3. Исходя из пункта 2, подобная статья может быть уже написана до меня. Я не знаю.

Ну и напоследок: статья, конечно же, субъективная, я никого ни к чему (воевать с фабриками) не призываю. Это просто мое мнение :)

Более того, я всего лишь junior, но я просто вижу противоречия и говорю о них.

Хорошего дня!
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

    +5
    Я работал в куче крупнейших софтвеpных компаний — никто этими терминами из статьи не пользуется и ни разу на спросили на интервью.
      +2
      Да ладно, все знают, что паттерны нужны для интервью и ещё Java-программистам, там без паттернов даже в файл «Hello world» не запишешь.
        +5
        class HelloWorld 
        { 
            public static void main(String args[]) 
            { 
                System.out.println("Hello, World"); 
            } 
        } 
        Какой паттерн?
          +15
          Ужасный код — ни одного паттерна =)
            +9

            А если вам понадобится завтра другую фразу вывести? А если не на экран, а в файл, или по сети, или брокеру сообщений? А если этот код будет кем-то вызываться в многопоточной среде? Нет, тут без пары абстрактных фабрик никак не обойтись.

              +3
              … тут без пары абстрактных фабрик никак не обойтись.

              О, я такое видел… когда один несчастный вызов curl был обернут во все вот это вот, но при этом не было никакой обработки ошибок :)
                +6
                Вы про вот такую реализацию Fizz-Buzz?
                github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
                  +3
                  Это высший пилотаж, недостижимый идеал, к которому каждый, тем не менее, должен стремиться.
                    0

                    Смешанные чувства… но я сохраню это)

                  +1
                  Стыдно не знать — Front Controller ))
                    0
                    Вроде, Front Controller к веб-сайтам относится:)
                    A controller that handles all requests for a Web site.
                      +1
                      Ну, это как бы иллюстрация к тому, о чем статья: желательно понимать идею, которая стоит за паттерном. Главное по ссылке: «The Front Controller consolidates all request handling by channeling requests through a single handler object» для того, чтобы избежать "...much of this behavior can end up duplicated. Also, it's difficult to change behavior at runtime.". Важно, что все запросы проходят через одну точку и за счет этого их потоком легче управлять и вообще понимать, что происходит с их обработкой, а не то, что это веб-сайт или не веб-сайт. Например, если установить правило, что все запросы в ваш отдел всегда проходят через определенного сотрудника, это вполне будет реализацией этого паттерна.
                        0
                        Походит на «Посредник» :)
                        чел, если у тебя есть много разных объектов, сделай один центральный, к нему подключи все остальное.
                0

                Меня изредка спрашивают. Недавно был на собеседовании в одной очень крупной компании, спросили, какие паттерны я знаю и использовал в коде.

                  +5
                  Вообще подобные вопросы на мой взгляд бесполезные. Те если работодатель реально хочет проверить соискателя то нужно или дать код написать или скажем оценить уже написанный. А спрашивать просто названия шаблонов такое себе на мой взгляд. Или вопросы на расшифровку solid. Это ещё глупее как по мне.
                    0
                    Чем вопрос про SOLID — то плох?
                      +4
                      Ну просто человек может не знать абревиатуру, но писать хороший код. Знание или не знание самого термина не особо помогает при опросе кандидата. Написать или найти недостаток в коде как по мне более действенный метод оценки кандидата
                        0

                        Если человек не знает аббревиатуру, значит, мимо него прошло ощутимое количество литературы и обсуждений. Это не значит, что он пишет плохой код, конечно же, но это тоже некая характеристика.


                        Что характерно, если человек знает аббревиатуру, это тоже не значит, что он пишет хороший код (или хотя бы понимает, что в реальности означает каждая буква в аббревиатуре).

                          0
                          Да я с этим согласен. Но на работе нас все-таки интересует как человек работает(пишет код). Поэтому и некий скепсис к знанию самих названий
                            +1

                            А то, как он пишет код, связано с тем, что он читает и обсуждает. И, что важнее, то, как он будет писать код через год-другой.

                              0
                              Ну опять же человек может очень много читать и развиваться, но не помнить/заучивать какие — то абревиатуры
                                0

                                Угу. А на работе он "может" много читать требования, но не помнить ключевые термины из них.

                                  +1
                                  Ну всякое может быть. Я не говорю что не надо знать термины. Моя мысль, что дать написать код более эффективно, чем спрашивать определения и абревиатуры
                                    0

                                    А наиболее эффективно — и дать написать код, и спросить термины.


                                    Особенно если в коде есть примеры на эти термины.

                                      0
                                      В идеале наверное да. Реально обычно времени не хватает. По моему опыту по крайней мере обычно не хватает времени
                                        0

                                        Это означает только то, что собеседование плохо спланировано. Если нет времени задать человеку вопросы, какой вообще смысл?

                                          0
                                          Ну если вам всегда хватает условного часа на то чтобы узнать общую инфу о кандидате, его прошлый опыт и задать все технические вопросы — мое уважение вам. Я не настолько крут
                                            0

                                            Я просто никогда не планирую собеседование в "условный час".

                                              +2

                                              Я не так уж и часто меняю работу. Скажем где-то каждые 3-5 лет. И если я уж решил её поменять, то чтобы не менять шило на мыло, я обычно спрашиваю о возможности "поторчать" на новой работе с новыми коллегами один день. Даже может и немного "поработать". То есть посмотреть процессы, пощупать тулсы, увидеть как работают мои потенциальные коллеги.


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

                              0

                              Ну это зависит. Я во всех этих ср дискуссиях про ООП участвую периодически, но из SOLID вспомню только что-то там про single responsibility principle, потому что оно первой буквой идёт, и про то, что в каждом обсуждении возникает мысль, что все остальные принципы самоочевидные.


                              Если у меня всерьёз начнут спрашивать по терминологии, то у меня возникет большое желание спросить интервьювера в ответ о (так, ООП, да?), например, принципе подстановки Лисков, как это связано с иммутабельностью, и плавно перевести разговор в то, какие элементы лямбда-куба потребуются для реализации ООП в чистом функциональном языке программирования, и насколько глубоко (нужна ли вся System Fω, или хватит её подмножества, и, кстати, раз зашёл разговор, что такое ω и какое отношение это имеет к арифметике ординалов).

                                0

                                Ну, я же вам уже рассказывал в одной дискуссии, чем это потенциально может закончиться?

                                  +1

                                  Чем это закончится, уже будет не так важно, так как после вопроса про расшифровку аббревиатур мне будет интереснее не максимизировать вероятность трудоустройства, а минимизировать ощущение потраченного на интервью времени, а встать и выйти не позволяет врождённая скромность.


                                  Но разговор-то не о том, чем это закончится, а о том, какие вопросы имеют смысл и почему. Мне вот вопрос про то, как сделать ООП, и что для этого нужно, представляется куда более интересным, чем вопрос на зазубривание аббревиатур.


                                  Да и вон eumorozov ниже про теоретические основы говорит. А это разве не теоретические основы?

                                    0
                                    Чем это закончится, уже будет не так важно, так как после вопроса про расшифровку аббревиатур мне будет интереснее не максимизировать не вероятность трудоустройства, а минимизировать ощущение потраченного на интервью времени, а встать и выйти не позволяет врождённая скромность.

                                    И это тоже вполне может быть желаемым для (несостоявшегося) работодателя результатом.


                                    Мне вот вопрос про то, как сделать ООП, и что для этого нужно, представляется куда более интересным, чем вопрос на зазубривание аббревиатур.

                                    А вопрос про SOLID (правильно заданный) — это не вопрос на зазубривание аббревиатур. Это вопрос на общий контекст.

                                      0
                                      И это тоже вполне может быть желаемым для (несостоявшегося) работодателя результатом.

                                      Ну супер, побыстрее разобрались, кто кому нужен и зачем. Он пусть дальше ищет тех, кто знает расшифровку SOLID назубок, но не знает, что там в основе лежит (я не зря про всю эту лямбда-ерунду начал говорить с LSP), я пусть дальше ищу тех, кому будут интересны (или кого не отпугнут, хехе) мои прочие познания.


                                      А вопрос про SOLID (правильно заданный) — это не вопрос на зазубривание аббревиатур. Это вопрос на общий контекст.

                                      Ну, ваш же тезис:


                                      Если человек не знает аббревиатуру, значит, мимо него прошло ощутимое количество литературы и обсуждений.

                                      Я его немного додумал, конечно (в частности, я сделал вывод, что из вашего тезиса следует, что вопрос на знание аббревиатуры вполне подходит для собеседования).

                                      0
                                      Мне вот вопрос про то, как сделать ООП, и что для этого нужно, представляется куда более интересным, чем вопрос на зазубривание аббревиатур.

                                      А "ООП" это не аббревиатура? А почему вы тогда здесь написали "ООП", а не просто описали весь концепт своими словами? :)


                                      Так и с аббревиатурами на собеседовании(да впрочем и в работе): если вы не знаете базовых для вашего поля деятельности аббревиатур, то начинаются проблемы с пониманием и объяснением. И на это уходит куча времени и сил.


                                      П.С. Правда открытым остаётся вопрос что и где можно/нужно считать базовыми понятиями/аббревиатурами.

                                        0
                                        А "ООП" это не аббревиатура? А почему вы тогда здесь написали "ООП", а не просто описали весь концепт своими словами? :)

                                        Я не понимаю связи этого вопроса с моим тезисом. Но если бы у меня на собеседовании спрашивали расшифровку «ООП», я бы тоже, скажем так, озадачился.


                                        Так и с аббревиатурами на собеседовании(да впрочем и в работе): если вы не знаете базовых для вашего поля деятельности аббревиатур, то начинаются проблемы с пониманием и объяснением.

                                        А я устраиваюсь теоретиком в ООП, что ли, писать книжки вместе с Дядей Бобом?

                                          0
                                          Я не понимаю связи этого вопроса с моим тезисом.

                                          Связь в том что даже если вы начнёте обуждать ваше "как сделать ООП, и что для этого нужно", то вы не обойдётесь без аббревиатур. И если в какой-то момент вам нужно будет упомянуть концепт вроде "SOLID" или просто одну из его составляющих, то если вы не знаете как он называется/его аббревиатуру вам придётся и его описывать своими словами.

                                            0

                                            Да, безусловно.


                                            Но, скорее всего, сам концепт целиком упоминать не придётся. Конечно, мы пройдёмся по некоторым его составляющим, но их даже упоминать явно не придётся, и уж тем более в том виде, в котором они упоминаются в расшифровке этой аббревиатуры.

                          +2
                          Меня мягко говоря подбешивает когда на собеседованиях начинают устраивать теоретические экзамены. Да не помню я что такое ООП, Фабрика, Наюлюдатель и прочие термины и помнить не хочу, я хочу писать код, а когда надо что то вспомнить открою справочник или доку. С чего вдруг джуниору или пре-джуниору знать все это наизусть, одних колекций в джаве вагон и тележка и что бы их понимать и знать когда и где их применять надо иметь опыт их использования, а джун на то и джун что опыта у него нет.
                            +3

                            Это вопрос спорный. Побыв с другой стороны баррикад — нанимая людей, чтобы работать с ними, поражаешься какое количество людей не знает теоретических основ вообще. Начиная порой с таких банальных вещей как рекурсия. Какие-там Domain-Driven Development или паттерны.


                            По моему скромному опыту, затем эти люди пишут просто отвратительный код. Реально отвратительный. Да, они могут писать. Но они не понимают разницы между iterable, iterator, container, list и set. Поэтому, например, в их коде любой iterable всегда приводится к list, потому что это — единственное, с чем они умеют работать.


                            Они могут выполнить любую задачу, возможно, но делают это в виде стены нечитаемого кода с жуткими 5-кратными вложенными операторами if, циклами, и т.п.


                            Этот код потом разлетается от малейшего дуновения ветерка и совершенно невозможно расширять. Любое малейшее изменение требований приводит к тому, что рядом встает вторая стена кода, а количество ошибок растет как N^2.


                            И справедливости ради, меня никогда не просили дать дословные формальные определения каждого паттерна, скорее, интересовались, о каких слышал, и как применял.


                            P.S. С другой стороны, все адские проекты и программисты из ада, которые я видел, продолжают существовать. Есть продукт, код которого я видел лет 14 назад, в котором разработчики не знали о вызове процедур, и заменяли его copy-paste'ом повторяющегося кода (серьезно). Этот продукт до сих пор на рынке (не знаю, правда, возможно за 14 лет его не раз переписали). Поэтому хотя работать с таким кодом и людьми мне кажется адски тяжелым, но жизнь показывает, что бизнес, основанный на адском коде вполне может существовать десятилетями. Увы.

                              0

                              Простите, а когда вы использовали в своих проектах рекурсию в последний раз? И что плохого в том, что ужасный код приносит деньги? Будучи идеалистами, разработчики часто ставят себе задачи идущие в разрез с целями бизнеса. Только позже приходит осознание, что код пишется для продажи, а не для девелопера. Возможно, в open source немного другая культура.

                                +2
                                Простите, а когда вы использовали в своих проектах рекурсию в последний раз?

                                Это серьезный вопрос?

                                  0
                                  И что плохого в том, что ужасный код приносит деньги?

                                  Плохо то что он приносит деньги только до тех пор пока его не надо изменять, исправлять или расширять. И вот тогда он внезапно начинает стоить очень много денег.


                                  Только позже приходит осознание, что код пишется для продажи, а не для девелопера

                                  Ага. Я это "позже" уже много раз в своей профессиональной жизни встречал. Ну то есть когда "позже" все начинают удивляться почему добавление простейшей фичи занимает три недели и/или сопровожается кучей багов. Ведь вроде бы раньше таких фич по пять штук в день могли клепать…

                                +1
                                Да не помню я что такое ООП, Фабрика, Наюлюдатель и прочие термины и помнить не хочу, я хочу писать код

                                Ну, это — конкретное отношение. Можно спорить, плохое оно или хорошее, но тимлиду оно может не нравиться, потому что он считает его вредным для работы, и тимлид в своем праве.


                                когда надо что то вспомнить открою справочник или доку

                                Для этого надо знать, что искать. А обычно задача стоит в другую сторону.


                                С чего вдруг джуниору или пре-джуниору знать все это наизусть

                                Ну, лично я от джуниора этого знания и не ожидаю (пока он сам им не решит похвастаться), в моем словаре этот вопрос на уровень повыше.

                                  +1
                                  Можете рассказать, какие знания вы ожидаете от джуна? Спрашиваю с позиции студента
                              0
                              Хм, а у меня почти каждый раз спрашивают… Правда, я на собеседования хожу редко и, в основном, просто так (я фрилансер, и мне иногда интересно сходить живьем посмотреть на других программистов).
                                0
                                В течение этого месяца побывал на 15 собеседованиях, примерно на 10 из них спрашивали про паттерны, какие знаю, какие использовал и прочую дичь. c#
                                +1
                                учите концепции, а не паттерны. Концепции реально важны.

                                Вопрос только в том, по какому "учебнику".

                                  0
                                  Вопрос про учебник и для паттернов актуален, особенно когда на собеседовании тебя спрашивают просто что такое XXX. Я даже как-то захотел показать это на примере и найтинесоответствие названий в разных книгах. В итоге обошелся одной бандой четырех — у них wrapper это синоним сразу и адаптера, и декоратора (я на всякий случай даже нашел английское издание 94 года — там так же)
                                    +1

                                    Для паттернов они по крайней мере есть. А вот найти учебник, в котором были бы концепции, но не было бы паттернов...

                                  0

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

                                    0

                                    Меня на собеседованиях иногда спрашивают, как бы я спроектировал распределённый кэш/распределённую ФС/распределённую шину данных (блин, что-то всё распределённое), и как-то разговор идёт скорее не о том, где бы я фабрику использовал, а где бы визитор, а об алгоритмах, допущениях и гарантиях системы.

                                    +1
                                    учите концепции, а не паттерны. Концепции реально важны.
                                    А почему не все сразу? По мне больше важнО не знание, а умение применять то что знаешь правильно.
                                      +5

                                      Если я правильно понял автора, суть в том, что при владении концепциями (и правильном применении их, да) известные паттерны будут получаться естественным путём, а значит, нет смысла им следовать целенаправленно.

                                      +7

                                      Знание паттернов полезно для того, чтобы все участники процесса говорили примерно на одном языке и схожие вещи называли одинаково. Например, не называли фасад посредником. Тогда не погружаясь в детали реализации каждого класса можно примерно понять, что он делает, и сэкономить время.
                                      Незнание паттернов, в свою очередь, может приводить к их повторному изобрели — что, безусловно, является отличной зарядкой для ума (да и понимание в этом случае глубже, чем если в учебнике прочитать), но не всегда оптимально с точки зрения трудозатрат.

                                        0

                                        "Что бы" — вместе, а "неправ" — раздельно.)

                                          +2
                                          больше пишите и читайте чужой код, понимание само придет, я когда первый раз прочел «Банду четырех», понял что я уже много чего и сам использовал, сам того не понимая.
                                            0

                                            КМК, знание паттернов необходимо, чтобы взгляд за код цеплялся. Очень помогает разбираться в чужом (да и своем) коде. Иначе придется детально вникать в каждую строчку кода, подавляя многочисленные wtf. Копаясь в строчках общую картину можно и упустить.

                                              +1
                                              Ну не знаю… некоторые налепят в именах классов названия паттернов, которые эти классы типа реализуют, но забудут, например, как-то в имени отразить, зачем, собственно, этот класс нужен. Толку от того, что у нас есть ФабрикаНепонятноЧего? Ну или кроме декларируемой роли еще какую-нибудь абсолютно левую функциональность в класс засунут… ну, чтобы интереснее было потом искать, где данные портятся.
                                              … придется детально вникать в каждую строчку кода, подавляя многочисленные wtf.
                                              По меему, это сама суть софтверной археологии.
                                                +2
                                                софтверной археологии

                                                Ага, теперь я знаю, как красиво обозвать первую стадию рефакторинга говнокода легаси! Спасибо.
                                                  0
                                                  Согласен, но это другая крайность, типа фабрики фабрик визиторов. KISS в помощь.
                                                +1
                                                Ну observer это не совсем
                                                парень, а давай намутим интерфейсов?

                                                А сами паттерны это столько не про формализацию, сколько про типичное решение типичных проблем, что очень нужно знать джуну, но синьор и так напишет то же самое, даже не помня про конкретный паттерн.
                                                  0

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

                                                    0

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

                                                      +2
                                                      Data mapper»: а почему бы тебе не использовать дополнительный слой абстракции для сохранения данных?


                                                      Мне очень понравился стиль. Может следующей статьей напишите продолжение описания многих концепций таким же неформальным языком? Потому что по сути мы читаем сухое описание, а между собой стараемся в 2 х словах описать.
                                                        0
                                                        Поделитесь, пожалуйста, какие паттерны Вы наиболее часто используете в работе. Т.е. хочется список, с которым джуниор ну на 100% столкнется, чтобы изучить их в первую очередь.
                                                          0

                                                          Builder, factory, repository(и/или DAO — вообщем уметь работать с абстракциями БД) — это если бэк(я про Java, хотя подозреваю, что в других отраслях также или легче) и начальный уровень.


                                                          Я написал это по Вашей просьбе, но не по душевному веянию, так как учить по паттернам, не зная зачем это нужно(концепции) — я считаю неправильным. А все это умещается в три замечательные концепции, описанные в статье, а если хочется пойти немного дальше — IoC и его реализация DI, если предмет изучения — Java enterprise, то там это точно пригодится(ибо Spring).

                                                            0
                                                            Спасибо, действительно имелась в виду Java. На счет использования паттернов, не понимая зачем это нужно, тоже соглашусь. Брать паттерн и подгонять под него свою задачу, конечно, неправильно
                                                          +3
                                                          Так получилось, что на старте своей карьеры первые два года своей работы я не знал ни одного паттерна. Но то самое понимание самих концепций привело к тому, что я неосознанно использовал некоторые паттерны. Потом, когда первый раз читал литературу по паттернам, я периодически ловил себя на мысли «ух ты, а я этот паттерн уже использовал в своём коде».
                                                            +1
                                                            По-моему, это у всех так.
                                                              0
                                                              Не у всех, к сожалению. Некоторые просто начинают применять их бездумно, потому что Так Правильно.
                                                            +1
                                                            Хорошего дня!

                                                            или утра… или вечера…
                                                              0
                                                              Концепции не конфликтуют с паттернами, а объясняют их происхождение. Да, зная исходные принципы можно вывести многие паттерны, но я, например, часто смотрю новые паттерны просто для вдохновения, чтобы понять, что «эту задачу можно решить ещё и вот так». Конечно можно и без паттернов, я первые пять лет работы вообще боялся этого слова, оказалось они очень просты и от них есть польза, если применять из без фанатизма. Плюс помогают в коммуникации, проще сказать «добавь туда фасад», чем «сделай функцию, которая пребразует исходный интерфейс в нужный», просто меньше слов.
                                                                0
                                                                «Я воспринимаю паттерны в своём коде как плохое предзнаменование. Код должен отражать только ту проблему, которую решает программа. Любые другие регулярности означают, по крайней мере, для меня, что мои абстракции недостаточно мощны, как будто я пытаюсь развернуть вручную некий макрос, который должен был написать.»

                                                                Пол Грэм.

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

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