Из приведённого вами материала, я бы сделал другую вещь. Сама по себе валидация несет несколько целей:
— Проверить можно ли продолжать, к примеру регестрировать пользователя в системе.
— Если возникли ошибки, вывести какое-то уведомление.
Я здесь вижу совершенно другой подход: обернуть логику проверки правильно веденных данных в валидатор. У валидатора сделать ивент, и на этот ивент подписывать заинтересованные классы. Например какой-нибудь Класс WrongUsernameReaction, который будет выводить сообщение об ошибке, и т. д. Т. е. максимум обсервер, никаких Composite.
Исправьте в первом примере Validate на ValidateUser или наоборот.
По-существу: вы хотите сказать, что приведенный ниже велосипед получился красивее, нежели оригинал? Сомневаюсь, начали с Composite, в итоге просто грубо говоря вынесли интерфейс (Validate) и сделали обертку над коллекций валидаторов. В итоге Composite не получился, а получилась адска обертка сочетающая в себе и поведенческую логику и элементы интерфейса :)
Как о человеке — да никакую, но я я говорил о другом, что сам предпочитаю получать такие вопросы на собеседовании ;) О психологии человека точнее может сказать HR, а я как человек воспринимаю другого человека по моторике, невербальном общении и характеристикам его речи.
К слову сказать, почему-то все компании взяли за правило при приеме на работу, давать распечатаные тесты с БреинБенча advanced level, и потом проводить техническое собеседование по конкретным прикладным направлениям…
Если речь зашла о бинарном поиске, какую же ошибку все допускают в сравнительно простом алгоритма, если не секрет?
Я предпочитаю для быстроты понимания for, так как он четко отображает границы цикла, и при применении префиксного декримента (--i) по скорости работы не уступает while. Ну а чтобы позабыть как работают операторы — это не знаю, нужно лет 10 не программировать, так как по-сути операторы одни и те же во всех языках, но различаются семантикой.
> Тупая зубрёжка апи. Где здесь натура человека, природа, область знаний, аналитическое мышление? Где?
Я c вами не согласен. Этот вопрос отображает опыт человека, хоть как-то, а подобные задачки типа сортировки или поиска делением пополам все когда-то решали будучи в институте, т. е. если это нужно будет, и если человек этого не знает, то алгоритм гуглиться в течении 5 минут, и применяется к конкретной ситуации. Конечно, кто-то может возразить, что это не правильно, но я считаю, что лучше уметь правильно применить существующий алгоритм, чем по памяти сделать неправильно :)
Ну и последнее, что я хотел сказать. Да, каюсь, я не помню такие вещи из стандарта языка, как частичная инстанциация шаблонов, и вообще многое о шаблонах, и не помню многое из книги Александреску, просто потому, что я НЕ ИСПОЛЬЗОВАЛ это уже как два года. Однако два года назад все эти вещи отскакивали у меня от языка, и по знаниям плюсов, и всяких заковыристых штучек я мог бы дать фору любому Сеньйору. Однако это вовсе не говорит о том, что раньше я был лучшим программистом, скорее наоборот.
Вот потому всякие штуки касательно языка, особенности, мелочи, и прочие Exceptional вещи стоит спрашивать у джуниоров, просто потому, что более у них нечего спросить, опыта у них нет, и оценить их как специалистов — очень сложно. Человек, которые поработал в отрасли професионально, просто не допускает вещей, который могут приводить ко всяким Undefined Behaviour и прочим прелестям, просто потому, что эта привычка выработалась на интуитивном уровне. Из своего богатого опыта багфиксинга в С++ проектах, могу сказать, что баги из-за элементарных ошибок — это ну 10%, и их очень легко обнаружить, или пофиксить во время рефакторинга или Code Review. А вот кривое проектирование, или обильное использование тех же шаблонов — это действительно Pain In the ass, и отлаживать это очень сложно.
Есть конечно же фанбои языка, которые в 40 лет способны помнить такие вещички, что сам Саттер позавидует, но я видимо не из таких, и меня больше интересуют прикладные направления.
В Obj C например вообще нет булевского типа, его реализует самостоятельно, тем не менее Obj C — это надмножество над языком С (хотя в нем булевского типа тоже нет...). Человек, который является не только узкоспециализированным специалистом (я считаю, что человек всегда обязан постигать что-то новое, иначе он остановиться в развитии и начнет деградировать), всегда может забыть что-то элементарное или спутать его с чем-то. А код, подобный тому, что дан в примере, я всегда рефакторю, когда вижу…
Про нежелание учиться вы взяли с потолка, я говорю, что я не обязан знать, что к примеру E_FILE_NOT_FOUND — 0x80041003. Такие элементарные вещи я знаю, а про триграф прочел два года назад у Саттера, однако дело не в этом. Если бы я проводил собеседование по С++, я бы точно не стал валить человека из-за такой чуши, потому что я не самоутверждаюсь, когда задаю вопросы. Цель — узнать уровень человека, его натуру, природу, область знаний, присутствие аналитического мышления, а всякие элементарные вещички — забываються в процессе их не использования. Их мозг попросту вычеркивает, когда каждый день вы пихаете в голову огромное количество материала, который необходимо освоить по работе. А о тех, кто пытается завалить человека на таком элементарном действии я могу подумать только одно «Видимо более толкого ничего спросить не может». Лично я предпочитаю услышать на собеседовании вопрос «Какие методы перехвата API функций вы знаете», чем «Отстортируйте пожалуйста массив методом вставки»…
Не согласен, иногда даже в простой задачке по перестановке символов в строке местами, из-за волнения можно сделать промашку и пустить цикл на лишнюю итерацию. Однако из этого ничего не следует. На собеседовании в мою текущую компанию, я так и ступил, однако меня взяли. И не из-за того, что брать некого было, а из-за того, что по результатам собеседования (на котором были 6(!) человек, не более 4 одновременно), я показал свои знания и то, что подобная хрень со строками — мало играет роли :)
Вот если честно, 111 может получиться только из-за невнимательности, как у меня :) Я посчитал, 101. триграф кстати заметил, о них читал в свое время у Саттера. А потом сам себе злой буратино думаю «Постойте, но что будет на последней итерации, когда будет 1? Правильно, он сначала пройдет в цикл, а потом сделает декремент!» и вот тут-то логика дала сбой. В общем с подколом задачка.
Простите, а мне нет безумства до того дела, как в том или инном компиляторе, или фреймворке реализуеться булевские типы. Я программирую и под Windows и под Mac OS X, так коды ошибок и их формирование различаеться рказительно. Я бы предпочел писать человеческий while или for, вместо того, безобразия, что написано в примере.
Я бы назвал статью, вернее вторую ее часть «будьте лучшими» или «будьте оригинальными». Да и в обычные казалось бы вещи можно внести определенную долю новаторства.
Вы же совершенно разные вещи указали. Я речь вел не о программисте со знанием фотошопа. Я к примеру системный программист с опытом, но обладаю навыками программирования на php. По вашей логике, если бы у меня было 3 года опыта системного программиста и два года опыта веб программиста я бы даже на собеседование не попал, потому как написал лишнее?
Простите, у человека есть резюме, оно отображает то, чем он занимался все эти годы, может дать о человеке краткую характеристику. А вы говорите, выбросьте все лишнее, отрежьте там, отрежьте там, выкиньте здесь, оставьте только то, что мне нужно, т.е. индивидуальность вас не интересует, только если возрастной ценз. Я бы не пошел к вам работать и на 100 тыс. Знаете почему? Потому что программист — это исполнитель, но безликий. Да и человек с аналитическими способностями, и наличием доступа к информации в скором времени сможет решить ваши задачки, даже если он и ранее не сталкивался с подобным.
— Проверить можно ли продолжать, к примеру регестрировать пользователя в системе.
— Если возникли ошибки, вывести какое-то уведомление.
Я здесь вижу совершенно другой подход: обернуть логику проверки правильно веденных данных в валидатор. У валидатора сделать ивент, и на этот ивент подписывать заинтересованные классы. Например какой-нибудь Класс WrongUsernameReaction, который будет выводить сообщение об ошибке, и т. д. Т. е. максимум обсервер, никаких Composite.
По-существу: вы хотите сказать, что приведенный ниже велосипед получился красивее, нежели оригинал? Сомневаюсь, начали с Composite, в итоге просто грубо говоря вынесли интерфейс (Validate) и сделали обертку над коллекций валидаторов. В итоге Composite не получился, а получилась адска обертка сочетающая в себе и поведенческую логику и элементы интерфейса :)
К слову сказать, почему-то все компании взяли за правило при приеме на работу, давать распечатаные тесты с БреинБенча advanced level, и потом проводить техническое собеседование по конкретным прикладным направлениям…
Если речь зашла о бинарном поиске, какую же ошибку все допускают в сравнительно простом алгоритма, если не секрет?
Я c вами не согласен. Этот вопрос отображает опыт человека, хоть как-то, а подобные задачки типа сортировки или поиска делением пополам все когда-то решали будучи в институте, т. е. если это нужно будет, и если человек этого не знает, то алгоритм гуглиться в течении 5 минут, и применяется к конкретной ситуации. Конечно, кто-то может возразить, что это не правильно, но я считаю, что лучше уметь правильно применить существующий алгоритм, чем по памяти сделать неправильно :)
Вот потому всякие штуки касательно языка, особенности, мелочи, и прочие Exceptional вещи стоит спрашивать у джуниоров, просто потому, что более у них нечего спросить, опыта у них нет, и оценить их как специалистов — очень сложно. Человек, которые поработал в отрасли професионально, просто не допускает вещей, который могут приводить ко всяким Undefined Behaviour и прочим прелестям, просто потому, что эта привычка выработалась на интуитивном уровне. Из своего богатого опыта багфиксинга в С++ проектах, могу сказать, что баги из-за элементарных ошибок — это ну 10%, и их очень легко обнаружить, или пофиксить во время рефакторинга или Code Review. А вот кривое проектирование, или обильное использование тех же шаблонов — это действительно Pain In the ass, и отлаживать это очень сложно.
Есть конечно же фанбои языка, которые в 40 лет способны помнить такие вещички, что сам Саттер позавидует, но я видимо не из таких, и меня больше интересуют прикладные направления.