Designing and refactoring
Comments 106
+5
Я работал в куче крупнейших софтвеpных компаний — никто этими терминами из статьи не пользуется и ни разу на спросили на интервью.
+4
Да ладно, все знают, что паттерны нужны для интервью и ещё Java-программистам, там без паттернов даже в файл «Hello world» не запишешь.
+6
class HelloWorld 
{ 
    public static void main(String args[]) 
    { 
        System.out.println("Hello, World"); 
    } 
} 
Какой паттерн?
0
Он не ужасен. Это самый прекрасный и чистый код.
Учителя не могут учить ужасному коду!
Только то, что начинается после него — можно назвать ужасным.)
+1
Да, видел ранее :)
NewLineStringPrinter.java — для \n.
Какой популярный, надо тоже использовать ))
Сообщество опять же.
+15

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

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

О, я такое видел… когда один несчастный вызов curl был обернут во все вот это вот, но при этом не было никакой обработки ошибок :)
+3
Это высший пилотаж, недостижимый идеал, к которому каждый, тем не менее, должен стремиться.
+1
А если вам понадобится завтра другую фразу вывести?

KISS + YAGNI
+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.". Важно, что все запросы проходят через одну точку и за счет этого их потоком легче управлять и вообще понимать, что происходит с их обработкой, а не то, что это веб-сайт или не веб-сайт. Например, если установить правило, что все запросы в ваш отдел всегда проходят через определенного сотрудника, это вполне будет реализацией этого паттерна.
+1
Походит на «Посредник» :)
чел, если у тебя есть много разных объектов, сделай один центральный, к нему подключи все остальное.
0
Нет, у класса HelloWorld конструктор не приватный. А это значит, что можно создать несколько экземпляров класса снаружи. Что в свою очередь противоречит паттерну Одиночка.
code
class HelloWorld
{
    public static void main(String[] args) 
    {
        System.out.println("Hello World!");
        MyClass m = new MyClass();
        m.func1();
    }
    public int ret1() {
        return 1;
    }
}

class MyClass
{
    public void func1() {
        HelloWorld p = new HelloWorld();
        System.out.println(p.ret1());
        HelloWorld s = new HelloWorld();
        System.out.println(s.ret1());
    }
}

0

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

+2

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


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

+1

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


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

0

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

+2

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


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


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

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

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


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

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

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

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


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

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


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

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

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

Ну вот видите же: работает.


в частности, я сделал вывод, что из вашего тезиса следует, что вопрос на знание аббревиатуры вполне подходит для собеседования

Совершенно правильный вывод. Просто вопрос на знание аббревиатур и вопрос на зазубривание аббревиатур — это два разных вопроса.

0
Он пусть дальше ищет тех, кто знает расшифровку SOLID назубок, но не знает, что там в основе лежит


Вопросы «как устроена система типов и почему?» и «как моделировать предметную область средствами java-like ООП?» ортогональны друг другу. И, нет, люди прочитавшие тапл (в чем, кстати, особого достижения нет) не начинают автоматически хорошо понимать второй вопрос и писать поддерживаемый код, несколько примеров вполне себе знаю.
+1
И, нет, люди прочитавшие тапл (в чем, кстати, особого достижения нет) не начинают автоматически хорошо понимать второй вопрос и писать поддерживаемый код, несколько примеров вполне себе знаю.

Так фокус в том, что люди, знающие, что такое SOLID, тоже не начинают автоматически что-то там хорошо писать.


Проверять, как кандидат умеет моделировать предметную область, ИМХО лучше всего через обсуждение некоей игрушечной предметной области и её моделирования, а не через обсуждение, что какая буковка в аббревиатуре означает.


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

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


И все ещё ортогонально умению писать поддерживаемый код, проектировать и решать бизнесовые задачи в рамках той или иной предметной области, только если предметная область не состоит в написании компиляторов или статических анализаторов для языков программирования со статической типизацией и выводом типов. Люди в реальной индустрии до сих пор спорят о нужности и практической пользе var в c# и java, программируют на javascript, а вы хотите на собеседованиях разговаривать о теории (одной из), результатом которой являются несколько абстрактных языков программирования, на которых никто не пишет, ага.
+1
Люди в реальной индустрии до сих пор спорят о нужности и практической пользе var в c# и java, программируют на javascript, а вы хотите на собеседованиях разговаривать о теории (одной из), результатом которой являются несколько абстрактных языков программирования, на которых никто не пишет, ага.

Ну помечтать-то можно же, ну.

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

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


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


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

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

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


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

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

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

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

0

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


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

0

Если названия паттернов или принципов SOLID активно используются при разработке, то вполне важное. Не все готовы, например, при код ревью вместо "нарушение SRP, используй абатрактную фабрику" не просто расписывать что не так и что надо изменить конкретно типа "в этом методе ты и создаешь сложный объект, и отправляешь его по сети — раздели их, а то непонятно даже где создание закончилось и отправка началась". И, главное, почему это "не так" объяснять не надо.

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

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


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


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


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


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


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

-2

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

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

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

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

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


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

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

+1
Про рекурсию — ну по нескольку раз в год, это уж как минимум.
+1
Если ты работаешь с рекурсивными структурами данных, то так или иначе будешь использовать рекурсию. Либо развернёшь её в цикл с использованием стека или без.

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

В общем it depends.
+1
положить в базу, считать с базы

В базе может дерево лежать
0
… и даже если оно там не лежит на первый взгляд, индексы по таблицам могуть быть бинарными деревьями (да, и их кто-то наверное даже иногда разворачивает, только не на доске).
0
сложить/вычесть, то конечно тебе не нужно рекурсия.

Ну, технически сложение [натуральных чисел] определяется рекурсивно, так что даже в этом случае рекурсия нужна.

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

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

помниться кто-то говорил что «хорошие» программисты всегда пытаються сделать универсальное решение, что и чайник и утюг и стиралка всё было в одном устройстве, раз все они работают с теплом, водой и электричеством, так вот не надо так делать
0
Кстати, писать докуметацию на свой код с помощью UML — это хороший тон, за который угощают пивом, или просто эту документацию никто не ищет и не смотрит?
+1

Отвечу вам и Ar234 сразу.


Вот вам банальный недавний пример. Человек, один из тех, кто не понимает рекурсию, а так же, вряд ли способен внятно объяснить разницу между iterator и container, написал в методе сохранения объекта в ORM колбасу из 4-х вложенных операторов if, в которой делаются 3-4 вызова REST API сторонних (не наших) сервисов.


То есть, на любой чих, в любом месте, например, какая-то batch job будет обновлять данные объекты (а это нам необходимо периодически делать), будут, #*%^, возникать задержки на сохранении вплоть до нескольких минут! И когда пользователи через UI создают или меняют объекты данного типа (а это основные объекты, с которыми взаимодействуют пользователи нашего проекта), так же будут непредсказуемые задержки вплоть до нескольких минут. А если, не дай бог, на 500 мс пропал DNS, то при сохранении может возникнуть исключение, и объект не будет сохранен.


Или, когда, из-за таких головотяпов пришлось полностью рефакторить проект, потому что в говнокоде просто не было возможности исправить маленькую, но очень важную ошибку. Я не могу привести все подробности из-за NDA и просто не хочется делиться всеми подробностями fuckup'а, но суть в том, что архитектура в корне оказалась неверной, и развивать продукт на ее основе оказалось не то что сложным — просто совершенно точно абсолютно невозможным. И это не мое мнение, а мнение нескольких человек, в том числе это признал автор говнокода, когда его ткнули носом в эту проблему. Пришлось переписать едва ли не 80% проекта, потому что иначе ждала смерть. Ни исправить существующие проблемы, не добавить новые возможности в говноархитектуру было просто невозможно никакими силами.


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


P.S. При этом я уважаю людей, которые критикуют паттерны, и не используют их, и сам с опаской отношусь к Architecture Argonauts или как их там зовут. Но только когда это обоснованное мнение, основанное на изучении вопроса и обоснованном скептицизме, основанном на опыте и рациональных доводах. А не на том, что "говно-джуниоры, которых мы нашли на помойке, согласных работать за доширак, не понимают эти ваши паттерны-шаматтерны, но они за миску лапши смогут решать все вопросы бизнеса все равно».

0
я не спорю что есть недалёкие, которых в код пускать не стоит, но их можно с помощью тестирования отсеивать, + задания со звёздочкой, что будет если будет не 10, а миллион записей, кто-то сделает, а кто-то не сможет.
И вот тем кто не сможет надо более подробные технические инструкции давать ну и код ревью, оно и против адептов которые любят писать сложно помогает
-2

Люди обычно требуют от других того, чего сами выучили в университете, и за что их преподы гоняли на пересдачи. Для студентов паттерны, солид, асид — это магия. Для опытного разработчика — аксиомы, которая доведены до автоматизма и здравого смысла. Спрашивать академ вопросы на собесе — это самоутверждение закомплексованых неудачников. И не нужно врать что у Вас код написан по всем канонам. Даже в гугле велосипедов хватает, и это абсолютно нормально, если того требует бизнес.

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

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


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

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


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

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

+1
Можете рассказать, какие знания вы ожидаете от джуна? Спрашиваю с позиции студента
+1

Знание языка, на котором предстоит писать, на уровне "могу написать большой фрагмент кода/некрупную программу не обращаясь к соседу за помощью" (помощь и совет — две разные вещи), несколько написанных программ, хотя бы и учебных. Дальше все на уровне "поговорить".

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

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

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

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

0
Судя потому, что автор называет концепциями: ООП, MVC, ORM — вот по этим учебникам.
+1

"ООП, MVC, ORM" — это не учебники. Это аббревиатуры (причем разного уровня конкретики). И, честно признаться, учебников по MVC или ORM я не видел ни разу (не считая книг по конкретной имплементации, которые на концепцию никак не тянут), а обычно и то, и другое описывается в книжке про… паттерны. Типа PoEAA. Собственно, потому, что и MVC, и ORM — это паттерны.


Остается ООП. Ну да, можно учить ООП по учебнику ООП. Но мне вот интересно, сколько современных учебников по ООП не упоминают ни паттерны, ни SOLID?

0

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

+1

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

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

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

+7

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

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

КМК, знание паттернов необходимо, чтобы взгляд за код цеплялся. Очень помогает разбираться в чужом (да и своем) коде. Иначе придется детально вникать в каждую строчку кода, подавляя многочисленные 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. На счет использования паттернов, не понимая зачем это нужно, тоже соглашусь. Брать паттерн и подгонять под него свою задачу, конечно, неправильно
+4
Так получилось, что на старте своей карьеры первые два года своей работы я не знал ни одного паттерна. Но то самое понимание самих концепций привело к тому, что я неосознанно использовал некоторые паттерны. Потом, когда первый раз читал литературу по паттернам, я периодически ловил себя на мысли «ух ты, а я этот паттерн уже использовал в своём коде».
+1
Не у всех, к сожалению. Некоторые просто начинают применять их бездумно, потому что Так Правильно.
+2
Концепции не конфликтуют с паттернами, а объясняют их происхождение. Да, зная исходные принципы можно вывести многие паттерны, но я, например, часто смотрю новые паттерны просто для вдохновения, чтобы понять, что «эту задачу можно решить ещё и вот так». Конечно можно и без паттернов, я первые пять лет работы вообще боялся этого слова, оказалось они очень просты и от них есть польза, если применять из без фанатизма. Плюс помогают в коммуникации, проще сказать «добавь туда фасад», чем «сделай функцию, которая пребразует исходный интерфейс в нужный», просто меньше слов.
0
«Я воспринимаю паттерны в своём коде как плохое предзнаменование. Код должен отражать только ту проблему, которую решает программа. Любые другие регулярности означают, по крайней мере, для меня, что мои абстракции недостаточно мощны, как будто я пытаюсь развернуть вручную некий макрос, который должен был написать.»

Пол Грэм.
+1
ИМХО, паттерны придумали скорее для общения с коллегами, для того что-бы не описывать абстракцию несколько минут, а использовать одно слово.

Разумеется пытаться подогнать свой код под паттерны — бред. Если соблюдать SOLID и GRASP (в разумных пределах) они выстроятся сами по себе.
+1
ООП говорит: «чувак, я нашел наглядный и понятный способ представления программ».

Вот это конкретика! Вот это точность! Правда многие то же самое имеют в виду под ФП или под любой другой аббревиатурой. А вот фабрика и синглтон это размыто и неточно, да.

+1
идея->концепция->паттерн->реализация

А так как в большинстве случаев будущий программер начинает от обратного, с реализации, то и возникает подобный диссонанс.
Это ни хорошо ни плохо, просто так есть. В каком порядке этот путь проходить — ну как уж получится. При любом раскладе найдётся история успеха
+2
один модуль должен выполнять только одну задачу, не забывай об этом!

Интересно, почему так много ошибок в понимании S из SOLID? "A class should have only one reason to change" не означает что задача только одна. Это означает что пользователи модуля или используют его полностью или не используют никак.


Ну а посыл в статье нормальный. Я про это давно уже повторяю.

Only those users with full accounts are able to leave comments. , please.