Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

Часто используемые/спрашиваемые design patterns

Здравствуйте, на днях возникли следующие вопросы:

1. Какие базовые design patterns must know (понятно, что в идеале все) для junior ?
2. Какие самые распространенные design patterns ?
3. Какие design patterns спрашивают на собеседовании для junior С# / C++ ?

Я знаком с decorator, facade, adapter, strategy, bridge, abstract factory. Пишу на С# / C++, спец. паттерны под другие языки не предлагать :) . Заранее спасибо.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

1. Какие базовые design patterns must know (понятно, что в идеале все) для junior ?

<trollface>Те, которые спрашивают на собеседовании.</trollface>

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

согласен. в практике паттерны больше используются для сокращения количества слов при передаче задание от ответственного за дизайн ответственному за имплементацию. как в той известной байке с пронумерованными анекдотами. прогуглить по названию и ознакомиться с поведением — дели нескольких минут. я, например, так познакомился с паттерном Command. базовые, конечно в памяти застревают, но если если глобально, то тыщщи их..

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

скажите это ребятами из микрософта.. а то напридумали всяких эмвиси, эмвипи, датафактори, датадаптеров, стрингбилдеров, канекшенпулов и пр...
Можно подумать, что благодаря этому какчество продуктов микрософта сильно возросло, ага. А у них, между прочим, еще от третьей венды Continuous Integration во все поля.

Это, знаете, как мартышка и очки.

Спс всем за помощь с design patterns. Возник еще такой вопрос. Общая структура вопросов для junior C# / C++ на собеседовании такова:

Структуры данных
• Массивы и строки
• Связанные списки
• Стек и очередь

• Деревья и графы

Алгоритмы и «концепции»
• Сортировка и поиск
• Рекурсия
• Манипуляция битами

• Объектно-ориентированное проектирование

Реализация всего этого добра на С++ каких то особенных затруднений не вызывает, а вот с С# проблемы. Как быть с пунктами: сортировка, поиск, стек, очередь ? Ведь в C# уже есть готовые классы и здесь не нужно создавать все самому как на С++. Что тогда могут спросить? Пробовал на С# поиграться с связанными списками и деревья, но без указателей как то непривычно все это делать :) .

Может я слишком большую область охватил как в случаии с design patterns ? Правда ли, что на больше собеседований код пишется на листочке :) ?

Почитайте моё собеседование в Глобал лоджик. :))
Забейте, ходите и пробуйте себя, получайте опыт.

Больше задавайте вопросы, выясняйте детали по заданию.

P.S. Эти вопросы задавайте на собеседовании. Что хотят от Вас увидеть, решение задачи готовыми классами или работу с массивами, с примитивами.

Что тогда могут спросить?

Все, что есть в этой книге — www.twirpx.com/file/64362

Ее очень желательно прочесть, это фундамент фреймворка. Это нужно знать джуну, разве что можете не сильно заморачиваться с security и cryptography (треть книги)

А такое же, но по .NET Framework 4.0 есть? Или .NET Framework 3.5 пойдет вполне ?

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

сам изучаю C# и указатели в нем есть, какую вы книгу по C# читаете на данный момент?
Тоже слышал, что 90-95 из 100 процентов код пишут на листочке, да и лучше на листочке, чем в IDE, это как контрольная в универе, сперва надо подумать, а потом писать, а в IDE код вбил, если не правильно — переписал, как-то машинально даже не

задумываешся когда пишешь что-то, почти все на автомате.

сам изучаю C# и указатели в нем есть,
использовать там unsafe код — полный изврат
+1

unsafe в основном используется для переноса кода, врятле кто то будет юзать его напрямую.

Иногда маршаллинг с нативным кодом делается в две строчки unsafe или в 10-20 без него. Так что использовать можно, главное с умом :)

сам изучаю C# и указатели в нем есть, какую вы книгу по C# читаете на данный момент?
Рихтер, Шилдт, Троелсен. Там не только указатели можно использовать, но и другие фичи С++. Но зачем так извращаться с С# :-D ?
Если добавили — значит не спроста. На сколько я понял в С++ за счет указателей делали высокопроизводительные приложения. Самому стало интересно на счет указателей в C# нашел в гугле мини статью (несколько слов ): При обращении к массиву в .NET проводится проверка индексов, что может привести к значительно снижению производительности.
C# (safe) 2910 мс
C# (unsafe) 1560 мс

я конечно не фанат указателей, но если использовать их с умом, то может пригодится.

Если добавили — значит не спроста

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

Если немного протупить с указателями, то вместо мифического увеличения перформанса в 2 раза получим как минимум «программа выполнила недопустимую операцию, и будет закрыта» :)

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

так С# изначально создавался автором Delphi как замануха для Java и C++ кодеров.

От джуна больше требуется наличие знаний по базовому функционалу и хорошая соображалка — остальному можно научить. Потому больше люблю простые практические вопросы спрашивать, типа:
1) Проверить, что символ является числом, кроме ’0′. (И смотрю, будет ли кандидат рисовать 9 IFов...)
2) Что будет если в lock(...) передать DateTime, и почему именно так это устроено? (знать не требую, достаточно, если сможет ответить на 3 простых наводящих вопроса и объединить свои же ответы)

и др...

Зачем девять if(ов) или это шутка? Не знаю или я понял условие, но типа так:

char ch = 2;
if(ch > ’0′ && ch <= ’9′)
System.out.println("число");
else
System.out.println("не число");

Зачем девять if(ов) или это шутка?

Нет, некорые так и начинают отвечать)))

На практике доводилось фиксить багу, вызванную кодом:

if (ch == «1» || ch == «2» || ch == «3» || ch == «4» || ch == «5» || ch == «6» || ch == «6» || ch == «8» || ch == «9» || ch == «0» ){...}

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

В .Net есть и другие варианты решения:

Char ch = ’2′;
if ( Char.IsDigit(ch) && ch != ’0′ ) { ... }
--------------------
Regex regex = new Regex("[1-9]");
if ( regex.IsMatch( ch.ToString() ) ) { ... }

Я так понял, что осн. вопросы для junior приходятся на работу с char и string (StringBuilder) ? :)

Я думаю, это от волнения ребят так плющило. :))

p.s. В Java тоже можно через обёртку, не знал... век живи, век учись

if(Character.isDigit(ch)

Дмитрий, вот просто интересно, часто ли на практике в lock передают DateTime, и собственно вот откуда джуниор может это знать?
Просто такой вопрос скорее из разряда «прочитал ли ты главу № в книге X». Хотя, судя по вашему посту, вам все таки более интересен ход мыслей по вашим «наводящим вопросам».
Вообще, мне непонятно зачем джуниора гонять по деталям multithreading, когда далеко не каждый заявленый мидл, а то и senior отвечает на эти вопросы.

Андрей, постараюсь ответить на Ваш вопрос развернуто:

часто ли на практике в lock передают DateTime

На практике передавать в lock DateTime нельзя начиная с .Net 2.0 — это вызовет ошибку компиляции, но это можно было раньше и лавочка была прикрыта в виду не очень приятного бага, связанного с попыткой передать ValueType в lock.

и собственно вот откуда джуниор может это знать?

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

Просто такой вопрос скорее из разряда «прочитал ли ты главу № в книге X»

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

Хотя, судя по вашему посту, вам все таки более интересен ход мыслей по вашим «наводящим вопросам».

Да, т.к. я не экзамен провожу и оценок не ставлю. Мне интересно прощупать что человек знает, умеет ли он думать сам или только зубрить написанное в книге. Понять, где у него сильные стороны, за которые можно будет не волноваться, а где его нужно подтянуть или подучить. Также интересно посмотреть как человек будет вести диалог и обсуждать поставленную задачу: будет ли рассматривать несколько альтернативных направлений решения, будет ли фантазировать или честно признается, что чего-то еще не знает — это дает определенное понимание, как человек будет себя вести при обсуждении боевых задач на проектах и насколько легко и конструктивно можно будет вместе с ним обсуждать варианты решения тех или иных задач. На практике есть гугл, есть книжки, есть коллеги — если человек чего-то и не знает, при необходимости он быстро сможет это нагуглить или спросить. Незнание каких-то деталей — это еще не минус даже для сениора, тем более для джуна. А вот неумение мыслить и анализировать — это уже более серьезная проблема.

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

Если человек заявляет, в резюме, что он знает multithreading, то знать что такое lock он должен как минимум, как и знать, что lock принимает объекты ссылочного типа. Большего для ответа на изначальный вопрос ему знать не надо, но если соискатель сам готов углубиться и рассказать чуть больше, это только плюс.

По сути возвращаясь к самому вопросу о DateTime и lock:
Естественно соискателям, которые не заявили о знакомстве с multithreading и предварительно не сказали, что знакомы с lock, я этот вопрос не задаю. Из остальных, по моему опыту % людей отвечающих на него сходу один и тот же, что для сениоров, что для джуниоров. Остальным я задаю наводящие вопросы:
1) DateTime — это Value Type или Reference Type? Тут есть целое поле для диалога о различиях этих типов данных и их применимости. ИМХО, такое контекстное обсуждение более интересно, чем банальный вопрос по учебнику: «Что такое Value Type или Reference Type?».
2) Что такое boxing? — еще не встречал джуна, который этого не знал бы.
3) Что такое lock? Как он работает? Что принимает на вход? — если уж человек заявляет знание multithreading, то ничего сложного даже для джуна тут нет, тем более что я помогу человеку прийти к правильному ответу, если ход мыслей правильный, но есть небольшой пробел — заодно что-то новое для себя узнает.
Далее прошу объединить ответы 1)-3) для ответа на начальный вопрос. Там все очень просто:
1) DateTime — это Value Type по очевидной причине.
2) lock — принимает Reference Type объект, который и используется для синхронизации потоков
3) Что будет, если Value Type передать в reference Type? Правильно, произойдет boxing...
И того приходит поток 1, передает в lock DateTime, в результате создается boxed копия этого DateTime в куче, которая благополучно лочится... Приходит поток 2, передает в lock _этот же_ DateTime, но в результате создается _новая_ boxed копия этого DateTime в куче. Т.е. lock просто ничего полезного не делает, как если бы его вообще не было)))

Именно так это работало в .Net 1.0 и именно по этой причине сейчас вы получите ошибку еще на этапе компиляции.

Итого всего одним вопросом я получаю возможность прощупать:
— знание по Value Type vs Reference Type
— понимание boxing
— знание о lock

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

Андрей, надеюсь я ответил на Ваш вопрос?

спасибо, теперь junior трижды подумает перед тем как вносить пункт multithreading в резюме :-D .

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

семафоры, мьютексы и интерлоки

это входит в часть базиса фреймворка. Базис — он задекларирован.

А у нас джуна про патерны вообще не спрашивают. Если знает — хорошо, не знает — научится. А вот

сортировка, поиск, стек, очередь

— это на C++ есть в STL, и это джун должен знать. И спрашивают как, например, стек реализовать голыми руками и как использовать этот же стек из STL.

Если кому-то интересно, у меня остался пример стека на Java (Эккеля)
gist.github.com/...c384d6662423bfe

То есть, нужно создать, к примеру, список своими руками и также показать умение пользоваться STL списком ? Тот же принцип и с С# (создал что то сам и показал умения использовать готовый класс) ?

Да, именно так для C++. А вообще мы из собеседований тайны не делаем — www.fulcrumweb.com.ua/...nterview_stages. Тут и вопросы типовые и задачи даже старые боевые есть.

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

Куча каких-то не нужных собеседований. В итоге, потратите сутки и не найдёте работу. Сидят двадцать человек в трёх комнатах, никакого тебе карьерного роста.

Благо в Киеве много компаний, сможете выбирать.

Пришёл на час, поговорил, да — да, нет — нет.

Насчет кода на листочках, все таки все зависит от того, кто собеседует. Я лично вот очень не люблю такой подход, соотв. стараемся обходиться без такого.
Это как-то очень психологически давит на кандидата, сразу всплывает образ какого-то университетского экзамена:)
Да и в конце-концов, на листочке же программу не запускают :)

Уж лучше привести человека к своему рабочему месту и попросить чето написать на компе, это гораздо о большем скажет.

Это как-то очень психологически давит на кандидата, сразу всплывает образ какого-то университетского экзамена:)
В универе нормальному преподавателю хватит 30-40 мин. чтоб узнать знает ли студент его предмет. На собеседовании можно просидеть от 1 — 5 часов, взорвать себе мозг и в итоге получить отказ о_О .

Мне кажется, что проблема недостатка кадров связана с отсутствием четко определенной политики по подбору этих кадров.

Меня напрягает листок, я становлюсь неадекватным. :)))

наличие листка и «опытного» собеседника дает возможность изобретать новые методы/алгоритмы/концепции .. Fight fire with fire ©

Можете ознакомиться с Singleton и быть счастливым. :)

Если к собеседованию — тогда уже потокобезопасный, мало ли :p

Хазарти вам в свое время совеиовали молчать и слушать. Поэтому не пишите ерунды. Вот вам старая добрая статья www.javaworld.com/...gnpatterns.html Прочтите ее и ваше мнение о простоте синглтона должно поменяться.

Андрей, Вы это к чему?
К тому, если будут спрашивать про паттерны в первую очередь спросят про Singleton ? Это написано во многих рассказах про собеседование. Прошу прощения, если где-то был не прав. :))
Я слушаю Вас, Андрей.

Я к тому что синглтон не такой простой паттерн в имплементации как хотелось бы. Что и написали в статье еще 2003 году. И любой вменяемый интервьювер должен поднять вопросы затронутые в статье. На такие вопросы не только джуниоры но и синиоры 23+ не всегда отвечают.

Если хотитеиметь заначку на собеседование то синглтон не самый лучший вариант.

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

А если вы еще перечислите все шаблоны, которые встроены в язык и фреймворк — экзаменующий вообще упадет на опу, и поставит вам пять :)

Это хорошо если дадут выбирать.

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

Так что одним синглтоном не отделаешься.

Ну, не отделаетесь, так не отделаетесь.
Мне какая разница? :)) Зачем Вы мне об этом сообщаете?

Пишите автору поста

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

Не заморачивайтесь вы так, шаблоны — это не «серебряная пуля» :) Для джуна главное — это оформление кода, знание языка и фреймворка. Джун — на то и джун, чтобы знать все поверхностно. Некоторые шаблоны уже встроены в язык, например — Прототип — интерфейс IClonable, итератор — IEnumerator, foreach, Обозреватель — подписка на события. Мост — инстанцирование SoludBrush, GradientBrush. И так далее :) Вам от этого легче? :)

Вам от этого легче? :)

Нет, но спасибо за помощь :) . Просто готовлюсь к собеседованиям и пытаюсь углубленно изучить часто спрашиваемые design patterns .

Для собеседований, если только Вы не идете на роль архитектора, то, обычно, сильно по паттернам не гоняют.
Стандартная схема такая:
1) Какие паттерны Вы знаете?
2)* Потокобезопасность синглтона. Отличия использования синглтона от использования статического класса.
3) Из названных в 1) Вами же паттернов выбирается 1-2 и Вас просят описать их, возможно с какими-то дополнительными вопросами по ходу.

*В зависимост от Ваших ответов на другие вопросы и список паттернов, которые Вы вспомните в 1), в ряде случаев спрашивать о синглтоне нет смысла и лучше сразу перейти к более интересным паттернам.

Если я правильно все понял, то достаточно серьезно выучить потокобезопасный Singleton и 2 — 3 паттерна на свой выбор и пункт design patterns удачно пройдет :) ?

Это ведь антипаттерн проектирования, а их нужно всеми силами избегать. Или я не прав ?

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

Если хочеш действительно в глубь то GoF тебе в помощ.

Подписаться на комментарии