Ну как обогнал… В js async/await пришел из ts, ts синтаксис разрабатывает одна мелкомягкая компания, которая и реализовала этот паттерн изначально в c#.
К счастью, не имею опыта общения с ex-USSR-style конторами, но высокотехнологичные, модные и молодежные тоже страдают подобным. Свежий пример на личном опыте — ВК. Отказ без личного общения, лишь по полностью перекрывающему требования из вакансии резюме и полный игнор на просьбу о получении фидбека для последующего самоанализа.
Я даже подумываю, а не проводят ли они анализ интересов, сообщений в нутрях своей сети. Конспирология, конечно, но с таким не редко встречаешься.
PS: справедливости ради, признаю, что сам терялся после получения тестового задания, которое не выполнял в силу отсутствия времени/лени.
Так-то при реализации более менее сложных проектов сложно говорить в категориях хуже/лучше. Место компромиссу всегда есть. К счастью ли, к сожалению, но это факт.
Все же интернирование, ибо Ваш вариант больше похож на итерацию.
не запускается в начале
Имеется ввиду не наличие строки ldstr «abc» в самом начале кода, ибо в примере из статьи, судя по IL коду,
идет речь о методе Main из одной строчки:
Console.WriteLine("x" + "y" + "z");
По факту — компилятор «прочухал», что WriteLine-у скармливают константную строку («x»+«y»+«z» всегда то же самое, что «xyz»), а уже CLR автоматом добавит эту строку в пул интернирования еще до первой инструкции метода Main.
То есть вместо общепринятого в одном или в другом языке, давайте-ка придумаем свое, верно я понял мысль? Биндинг — изначально неправильное прочтения заимствования. Никакой оправданности или точности в нем нет (ну или я так слеп, что не могу усмотреть).
Возражу — доступность кнопки может быть обусловлена бизнес-правилами, а не UI. Если рассуждать не в контексте Кнопка, Доступность Кнопки, а в категориях Команда (отправка данных на сервер), Доступность Команды (не все поля заполнены), то вполне разумно в VM добавить такую функциональность, которую, к тому же, легко проверить тестами.
Был у меня небольшой солюшн под WP 7.5 с 3+ проектами. M зависела только от утилитарного проекта и DAL; VM от M + от утилитарного; V, соответственно, от VM (без M, то есть V не знал о M вообще). При переходе 7.x->8.x->UWP мне по большому счету приходилось менять только V.
Да, мне очень помог Caliburn.Micro, позволивший не пробрасывать из V во VM *EventArg и не городить лишних зависимостей. А там где нужно было завязаться на специфические API — все решалось через DI.
Больше свойств — больше связей, все их нужно синхронизировать и держать в голове при разработке. Конвертеры имеют меньше зависимостей.
В любом случае нужен взвешенный подход. Нельзя однозначно отказаться от конвертеров, ровно как и от подхода создания дополнительных свойств. Наверное, только с опытом придет понимания, как лучше поступить в том или ином случае. А универсальных и строго формализованных правил на этот счет сформулировать трудно.
И я не придумал лучшего способа, чем взять книгу «Паттерны проектирования» Эрика и Элизабет Фримен, и написать примеры каждого паттерна на Objective-C и Swift.
Плохая идея. Паттерны, это не про реализацию набора правил, это про применение этого набора правил в подходящем для этого месте. Хотя, может и нужно пройти такого рода эволюцию:
1) паттерн головного мозга — это когда только прочитал про них и везде, чаще не к месту, применяешь их;
2) просветление — это когда реально познал дзен и можешь аргументированно рассказать почему в этом месте нужен именно этот паттерн, а при немного других вводных при той же функциональности уже нет.
Ну и да, антипаттерн — это не про тот или иной конкретный паттерн, а про неправельное его применение.
А по поводу First Line… ну мой личный опыт таков, что я оттуда ушел спустя 4 или 5 месяцев работы, не меня уволили, а именно я искал куда бы поскорей перейти. Ушел в другую аутсорс-компанию, в которой уже почти 3 года. При сравнении однозначно скажу, что сделал правильный выбор (по многим критериям).
Не берусь утверждать, что там плохо для всех и для каждого — непосредственно контактировал с ребятами, которые там уже больше 6 лет и их устраивает.
PS: не троллинга ради, реально не понял о чем Вы.
Я даже подумываю, а не проводят ли они анализ интересов, сообщений в нутрях своей сети. Конспирология, конечно, но с таким не редко встречаешься.
PS: справедливости ради, признаю, что сам терялся после получения тестового задания, которое не выполнял в силу отсутствия времени/лени.
Все же интернирование, ибо Ваш вариант больше похож на итерацию.
Имеется ввиду не наличие строки ldstr «abc» в самом начале кода, ибо в примере из статьи, судя по IL коду,
идет речь о методе Main из одной строчки:
По факту — компилятор «прочухал», что WriteLine-у скармливают константную строку («x»+«y»+«z» всегда то же самое, что «xyz»), а уже CLR автоматом добавит эту строку в пул интернирования еще до первой инструкции метода Main.
Возражу — доступность кнопки может быть обусловлена бизнес-правилами, а не UI. Если рассуждать не в контексте Кнопка, Доступность Кнопки, а в категориях Команда (отправка данных на сервер), Доступность Команды (не все поля заполнены), то вполне разумно в VM добавить такую функциональность, которую, к тому же, легко проверить тестами.
Серьезное заявление… проверять я его, конечно, не буду ©
Да, мне очень помог Caliburn.Micro, позволивший не пробрасывать из V во VM *EventArg и не городить лишних зависимостей. А там где нужно было завязаться на специфические API — все решалось через DI.
Годится такой пример?
В любом случае нужен взвешенный подход. Нельзя однозначно отказаться от конвертеров, ровно как и от подхода создания дополнительных свойств. Наверное, только с опытом придет понимания, как лучше поступить в том или ином случае. А универсальных и строго формализованных правил на этот счет сформулировать трудно.
«даже на Windows Mobile» как будто о старом добром Windows Mobile 6, но в то же время «владельцы люмий», как о Winows 10 Mobile.
В контексте заголовка, кодить-то может и научился… а вот разрабатывать пока нет.
Плохая идея. Паттерны, это не про реализацию набора правил, это про применение этого набора правил в подходящем для этого месте. Хотя, может и нужно пройти такого рода эволюцию:
1) паттерн головного мозга — это когда только прочитал про них и везде, чаще не к месту, применяешь их;
2) просветление — это когда реально познал дзен и можешь аргументированно рассказать почему в этом месте нужен именно этот паттерн, а при немного других вводных при той же функциональности уже нет.
Ну и да, антипаттерн — это не про тот или иной конкретный паттерн, а про неправельное его применение.
Но сейчас-то повзрослел… Зрелый язык, зрелое отношение к документации.
А по поводу First Line… ну мой личный опыт таков, что я оттуда ушел спустя 4 или 5 месяцев работы, не меня уволили, а именно я искал куда бы поскорей перейти. Ушел в другую аутсорс-компанию, в которой уже почти 3 года. При сравнении однозначно скажу, что сделал правильный выбор (по многим критериям).
Не берусь утверждать, что там плохо для всех и для каждого — непосредственно контактировал с ребятами, которые там уже больше 6 лет и их устраивает.