апотом забыть)

зазубрить перед собеседованиями

Хз, у нас на собесе гоняли по практической части

Грят, вот у тебя 1000 элементов на странице, нужно по клику добавить определённый в корзину

Как реализуешь

Сразу проверяют твои знания разора, жквери и тд

Сразу проверяют твои знания разора, жквери и тд

Без обыта?

Да

Ну я сказал что у меня год опыта под НДА

просто я вот щас набрал скок на десктоп вакансий

и чёт ахуел

Короче я б не рискнул

Джуновских 1-2 штуки, и в требованиях оракл и .нет 4.0

Абстрактный класс, это база для норм классов, по которым можно будет создавать объекты. Что-то типа заготовки

Похоже, что так

А интерфейс как-бы тоже самое

То же, только шире понятие

Это скорей договор, как должен работать объект

Когда понятно, чё он умеет и чо от него можно ждать

Скорее это соглашение о контрактах взаимодействия с внешним миром

а что там, вакансий под десктоп нет, да?

я просто по сайтам по поиску работы не хожу

а что там, вакансий под десктоп нет, да?

26 штук по иеву

3 жуновских

а на ашпнет?

100

занятно

и 10-15 жуновских

но походу что там что там

жуновские это текучка в основном

так что норм там от силы 3-4

мб 5

ну когда ты сеньор то тебе уже похер

самый убойный вопрос на самом деле, на какую минимум зп вы расчитываете?

тут люди из разных стран сидят и регионов

самый убойный вопрос на самом деле, на какую минимум зп вы расчитываете?

А если ты remote хочешь устроиться пахать мидом на Ижевск, будучи из Москвы, будешь просить зарплату мида Москвы или Ижевска?

А если ты remote хочешь устроиться пахать мидом на Ижевск, будучи из Москвы, будешь просить зарплату мида Москвы или Ижевска?

я джун, мне хватит зп джуна мск ?

то есть в ил нет различий?

то есть в ил нет различий?

есть только метки и конструкторы у неинтерфейсов

то есть в ил нет различий?

В IL есть различие: написано .class или .class interface :)

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

абстрактный класс может иметь реализацию методов, а при использовании интерфейсов можно использовать множественное наследие. Я всегда так отвечаю :D

абстрактный класс может иметь реализацию методов, а при использовании интерфейсов можно использовать множественное наследие. Я всегда так отвечаю :D

В интерфейсы тоже скоро запилят реализации методов.

можно ссыль почитать?

В интерфейсы тоже скоро запилят реализации методов.

это вряд ли

В интерфейсы тоже скоро запилят реализации методов.

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

абстрактный класс может иметь реализацию методов, а при использовании интерфейсов можно использовать множественное наследие. Я всегда так отвечаю :D

Еще и поля в аб. классах есть

смысловая нагрузка стандартной реализации методов не понятна, если честно

в интерфейсах

Да.

можно ссыль почитать?

https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md

абстрактный класс может иметь реализацию методов, а при использовании интерфейсов можно использовать множественное наследие. Я всегда так отвечаю :D

А разве можно это называть множественным наследованием?

это даже не оно так-то

Наследуют же обычно данные и функциональность, а тут, фактически, класс >реализует указанные методы/свойства. Множественное наследование в классическом понимании в C#8 завезут )

смысловая нагрузка стандартной реализации методов не понятна, если честно

Тут минут 5 про это расказывают https://youtu.be/KFqrp4KSxio?t=53m0s

интерфейс это контракт

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

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

О, а как ты видишь их использование? Для чего они, как считаешь?

Как и говорит название, для sane default implementations - те же абстрактные классы, но без состояний

В Scala они играют роль в миксинах, например

ERROR: S client not available

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

Зачем?

Да это всё опять сведётся к спору аля var не нужен. Завезут - хорошо, можно не пользоваться. Не завезут - ну и жили как-то

Как и говорит название, для sane default implementations - те же абстрактные классы, но без состояний

Не нужны

Да это всё опять сведётся к спору аля var не нужен. Завезут - хорошо, можно не пользоваться. Не завезут - ну и жили как-то

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

Господа! Посоветуйте, xUnit-ом обмазываться или NUnit-ом?

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

Я тоже недавно выбирал какой использовать. Пробовал читать статьи в интернете, типо такой: https://stackify.com/unit-test-frameworks-csharp/ Так и не нашёл особых описаний с адекватными аргументами за и против. Может не там искал. Для простоты взял MSTest из студии. А потом видно будет. Для большого проекта выбираешь? Всмысле перекатываться с одного на другой больно будет?

Господа! Посоветуйте, xUnit-ом обмазываться или NUnit-ом?

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

Или можно использовать ресолвер зависимостей

Учитывая, что в тестируемом приложении он и так, наверняка, используется

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

А что в xUnit'e за модерновый синтаксис такой? В NUnit есть два на выбор - стандартный Assert.Equals(..) и Assert.That(actual, Is.Not.Equals(..)). Ну и FluentAssertions можно в любом фреймворке использовать

Учитывая, что в тестируемом приложении он и так, наверняка, используется

как ты сделаешь глобальный объект в тестах, который нужен всем тестам, кроме как синглтоном?

А что в xUnit'e за модерновый синтаксис такой? В NUnit есть два на выбор - стандартный Assert.Equals(..) и Assert.That(actual, Is.Not.Equals(..)). Ну и FluentAssertions можно в любом фреймворке использовать

> в иЮните читать как в нЮните под модерновым я имел ввиду как раз Assert.That(actual, Is.Not.Equals(..))

понятно :)

С FluentAssertions тоже неплохо получается - actual.Should().NotBeNull();

Господа! Посоветуйте, xUnit-ом обмазываться или NUnit-ом?

xUnit.

А вообще, всё хорошо, что не MSTest.

А вообще, всё хорошо, что не MSTest.

+1

А вообще, всё хорошо, что не MSTest.

А какие у него минусы? Не троллинга ради, а реально интересно. Я просто не особо его щупал. Не в курсе. Пока всё устраивает. Разве что слышал что скорость неочень

а визуалстудиотестпро только с мстест работает?

а визуалстудиотестпро только с мстест работает?

Нет, со всем работает.

прекрасно. а то куплен лежит

Всем спасибо! Накатываю xUnit.

А какие у него минусы? Не троллинга ради, а реально интересно. Я просто не особо его щупал. Не в курсе. Пока всё устраивает. Разве что слышал что скорость неочень

Нет удобного сахара.

А какие у него минусы? Не троллинга ради, а реально интересно. Я просто не особо его щупал. Не в курсе. Пока всё устраивает. Разве что слышал что скорость неочень

1. Очень сложно установить раннер на билдсервер, если ты не хочешь туда ставить студию. Из нугета раннер не скачать, как для других фреймворков. 2. Есть такая омерзительная штука, как [DeploymentItem]: раннер за каким-то неведомым макаром хочет копировать тестовые DLL в секретные каталоги, и постоянно забывает перенести туда конфиги или зависимые DLL (например, EntityFramework.SqlServer), и его приходится превозмогать. 3. Конфигурации запуска (параллельность, необходимость shadow copying, надобность вот этого "deployment") редактируются в каких-то адских XML, не для всех из которых есть стандартные шаблоны в студии. В других фреймворках это же можно портабельно настроить атрибутами. 4. На Mono завести ещё сложнее, чем на виндовом билдсервере. У других фреймворков проблемы нет, потому что см. п. 1. Итого: я буквально на прошлой неделе настраивал билды с запуском xUnit и MSTest на билдсервере (TeamCity). И, если xUnit я сделал за десять минут, то с MSTest ебался с перерывом двое суток. Не люблю MSTest.

:) Ок. Спасибо

а с TFS норм всё у xUnit?

как ты сделаешь глобальный объект в тестах, который нужен всем тестам, кроме как синглтоном?

Контейнер, в смысле? Ну вообще я бы создавал его в инициализаторе тестов и не сохранял бы его состояние между тестами, ибо нахера? Но если очень хочется, то можно синглтон

А какие у него минусы? Не троллинга ради, а реально интересно. Я просто не особо его щупал. Не в курсе. Пока всё устраивает. Разве что слышал что скорость неочень

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

а с TFS норм всё у xUnit?

К сожалению, у меня опыта с TFS нет, поэтому подсказать не могу.