04.09.2012 16:41, MozgC пишет:

> Согласен. Я вот за собой замечаю нехорошую вещь: вот вроде есть уже и
> относительно немаленький опыт, и теоретические знания, читал разные
> умные книги и т.д. и т.п., а на практике бывает что в реальной работе об
> этом забываешь — напишешь код, и если потом критически на него
> посмотреть, то можно найти несколько "запашков".
Потому что в реальной работе требуется написать решение задачи за
ограниченное время, а на исправление всех "запашков" потребоваться может
бесконечность, а это деньги.

Здравствуйте, Piko, Вы писали:

H>>Я вот удивляюсь — в динамических языках нет адских шаблонов и метапрограммирования но почему-то это не только не мешает писать код, но и упрощает задачу.

Это в руби, перле, питоне и js нет метапрограммирования? Или ты про другие динамические?

Здравствуйте, Handie, Вы писали:

H>При программировании на PHP, JavaScript и т.д. люди пишут код, на С++ же часто демонстрируют силу духа и степень просветления.

Тебе про С++ ещё кошмары не снятся?

Здравствуйте, _FRED_, Вы писали:

_FR>На сколько задание сложное? То есть не "смогли бы вы его сделать?", а "Не должен ли каждый "взрослый" программист уметь обращаться с перечисленными (под катом) вещами?" Естественно, всё это требует навыков и опыта. Именно это и ожидается от кандидатов.
С моей точки зрения — всё ок, такой подход проверяет все скиллы будущего сотрудника, а не только умение кодить. "Спроектировать ... тип данных, который представляет из себя отрезок времени между двумя датами " с ходу не выйдет, нужна дополнительная информация. Всё как в реальной обстановке: люди не любят описывать контекст — не по злому умыслу, а просто "и так очевидно"

Будущий сеньор просто обязан спросить 2 вещи:
1. Описание предметной области и нюансы, про которые знает только эксперт в предметной области. Сотрудник может забыть/не знать про разницу в летнем/зимнем времени, leap seconds и прочие прелести — это абсолютно нормально. Ненормально, когда человек стесняется спросить: "что мне нужно знать перед тем как решать задачу?".

2. Затем — обязательно — попросить привести сценарии работы с нашим типом данных. Это буквально первая заповедь, её должен знать любой разработчик библиотек:

Framework Design Principle
Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.

(с) Framework Design Guidelines

Тут тоже может всплыть куча неочевидных вещей:
* может потребоваться работа с неограниченными справа/слева интервалами (с 1.01.2012 по бесконечность; по 31 января такогото года и т.д.)
* отрезок может включать/исключать конечные даты (с 12:00 первого сентября включительно и по 12:00 второго сентября исключительно)
* как насчёт объединения, сортировки, пересечения отрезков?
* что, если потребуется работать не с датами, а с другим типом?
* как насчёт составных интервалов/интервалов с "дырками"?

Если подобные вещи не спросить сразу — они всплывут потом, когда тип уже будет готов и непригоден к использованию

_FR>На сколько задание адекватное, то есть соответствует поставленным целям?
_FR>На сколько реально или даже должно выполнить его "тут же" за пятнадцать скажем минут (напоминаю, писать реализацию даже не обязательно, главное — обозначить решаемые проблемы, указать способ решения, не забыть перечислить все необходимые вещи, которые вы считаете обязательными).
Зависит от того, как именно вы уточните задание. Обычно дизайн (по крайней мере основные моменты) вырисовывается прямо по ходу беседы, когда каждое новое требование отсекает сразу несколько решений. Например, если надо хранить отрезок без правой/левой границы или нужен отрезок, способный работать с любыми типами данных, то логичнее будет хранить начало-конец интервала, а не "начало + длина"

Иногда требования могут прямо противоречить друг другу, или быть несовместимы с логикой. Если человек не "проглатывает" такие моменты без возражений, а начинает искать компромиссное решение, предлагает несколько вариантов (или отбрасываем работу с "дырками", или сильно усложняем логику работы) — это огромный плюс.

_FR>Ну вот, теперь снова придётся что-то другое выдумывать, если меня ещё допустят к собеседованиям после таких каверз
Почему? Правильное задание — это вешь в себе, по мере уточнения требований могут получаться весьма неожиданные результаты.

Например, шикарен вопрос: Дано: интервал1 — с 1 по 10 апреля. интервал2 — с 1 по 10 мая. Что должна возвращать операция объединения этих интервалов?

Здравствуйте, Sinix, Вы писали:

_FR>>На сколько задание сложное? То есть не "смогли бы вы его сделать?", а "Не должен ли каждый "взрослый" программист уметь обращаться с перечисленными (под катом) вещами?" Естественно, всё это требует навыков и опыта. Именно это и ожидается от кандидатов.
S>С моей точки зрения — всё ок, такой подход проверяет все скиллы будущего сотрудника, а не только умение кодить. "Спроектировать ... тип данных, который представляет из себя отрезок времени между двумя датами " с ходу не выйдет, нужна дополнительная информация. Всё как в реальной обстановке: люди не любят описывать контекст — не по злому умыслу, а просто "и так очевидно"

S>Будущий сеньор просто обязан спросить 2 вещи:
S>1. Описание предметной области и нюансы, про которые знает только эксперт в предметной области. Сотрудник может забыть/не знать про разницу в летнем/зимнем времени, leap seconds и прочие прелести — это абсолютно нормально. Ненормально, когда человек стесняется спросить: "что мне нужно знать перед тем как решать задачу?".

Предметная область такая же, как им для типа DateTime нарпимер или даже Int32 То етсь _примитивный_ тип данных.

S>2. Затем — обязательно — попросить привести сценарии работы с нашим типом данных.

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

S>Тут тоже может всплыть куча неочевидных вещей:
…
S>Если подобные вещи не спросить сразу — они всплывут потом, когда тип уже будет готов и непригоден к использованию

Ещё раз — я не прошу спроектировать тип, который мне нужен для какой-то конкретной задачи. Я прошу спроектировать примитивный тип, который сможет использоваться там, где нужно оперировать отрезком времени. И исходить нужно именно из такой постановки. Лично мне кажется, тут есть два пути — или оставтиь только самое необходимое (самому решить не сложно), что понадобится везде или выбрать что-то одно. Но если выбранное окажется узкозаточенным подо что-то одно — это слегка нарушит условие, а если это выльется в отдельную библиотеку — окажется перебором и несомненно уже переусложнизмом. Если я в постановке задачи сказал, что тип должен быть примитивен, то именно \это и имел в виду! смотрите: и Int32 и String вполне конкретны и очень ре-юзабельны. Тип который я прошу должен быть "как они".

Я ведь думаю как — ни заказчик "тётя Маша", как я уже сказал, ни проджект менеджер не станет взрослому программисту рассказывать, как ему проектировать элементарный тип данных. Человек получает задачу. Он её декомпозирует, решает, что ему нужно для реализации и реализует. Если каждый простейший тип нужно обсуждать с менеджером, то это явно не взрослый программист. Люди сами определяют, какие типы понадобятся для решения задачи, сами их пишут и поддерживают. Я хочу посмотреть как они умеют это делать. Как они свои знания об используемом языке-платформе применяют при этом.

От "взрослого" программиста я ожидаю умения решить, что ему нужно для решения задачи и реализации решения. Задача — написать примитивный тип самого широкого "спектра действия" (да даже узкого — разницы на самом деле _никакой_). "Широкого" я говорю как раз для того, что бы отстраниться от конкретной прикладной задачи. Ну вот позвольте мне аналогию провести. Я в институте несколько лет слушал лекции про болты. Я прошу вас спроектировать болт. Вы можете спросить, например, про нагрузку, которую болт должен уметь держать. Её я вам скажу. Пожалуй, это и всё. Из того, что я не скажу, что именно я буду скреплять болтом — лампочку там в машине прикручивать или ручку к каминной полке — следует лишь то, что детали связанные с такими тонкостями меня в данном конкретном задании не интересуют. Я хочу посмотреть, как вы рассчитаете болт, как выберете материал, резьбу и прочее. Но если при выполнении вы мне покажете какой-то очень уж экзотический и изощрённый болт (под заявленную нагрузку естественно) — я посмотрю на вас косо: зачем было впадать в крайности? Выбрали бы что нить попроще, что бы легче было бы разобраться.

Я же никакой ловушки не готовлю. Так с типами здесь тоже самое. Тут вот меня пытались обвинит в "переусложнизме", так по моему он наоборот с другой стороны :о) Это сложно не просто, но не сложнее, чем спроектировать вообще любой тип. Кода может быть немного побольше, но думать надо абсолютно так же, о том же, как при написании любого вашего типа. Поступать да, скорее всего по другому (в виду специфики общности типа) но думать и принимать в расчёт совершенно те же самые вещи.

Теперь вот посмотрим:

S>* может потребоваться работа с неограниченными справа/слева интервалами (с 1.01.2012 по бесконечность; по 31 января такогото года и т.д.)
S>* отрезок может включать/исключать конечные даты (с 12:00 первого сентября включительно и по 12:00 второго сентября исключительно)
S>* как насчёт объединения, сортировки, пересечения отрезков?
S>* что, если потребуется работать не с датами, а с другим типом?
S>* как насчёт составных интервалов/интервалов с "дырками"?

Это всё надо вспомнить-представить себе при проектировании. То есть это правильные вопросы которые, как я ожидаю, подходящий в данном случае человек _себе_ задаст А дальше посмотрит на задание и найдёт ответы. Потом он покажет, что у него получилось…

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

Или наоборот, сделает такую вещь, а я спрошу:
— Зачем вам это показалось необходимым? И код вот раздулся, и помимо двух концов отрезков хранить ещё их интерпретацию пришлось — размер увеличился — стоит ли?, и … [ну найду что сказать]".
А он мне
— А вот удалось так интерфейс сделать, что эта особенность и не заметна вовсе тогда, когда не нужна. А зато когда понадобится — окажется очень кстати.

Ну вот и с остальным примерно так же Шутка конечно, но, надеюсь, так понятнее.

Здравствуйте, _FRED_, Вы писали:

_FR>Предметная область такая же, как им для типа DateTime нарпимер или даже Int32 То етсь _примитивный_ тип данных.

Интервалы — это не примитивный тип данных, это целый набор абстракций со своими правилами операций, логикой и холиварами (являются ли ±∞ допустимыми значениями числовой прямой, могут ли существовать интервалы вида (a,a], допустимо ли объединение непересекающихся интервалов и т.д. и т.п.). Аналогично — с работой с временем.

Конечно, соискатель может решить, что ему виднее и самостоятельно выбрать сценарии по которым будет проверять свой дизайн. И, если повезёт, сможет обосновать свой выбор так, что не придерётесь. А На выходе — абсолютно корректный и абсолютно бесполезный код, потому что вы в голове держали совсем другие юз-кейсы. Ну и зачем оно нужно?


_FR>Ещё раз — я не прошу спроектировать тип, который мне нужен для какой-то конкретной задачи. Я прошу спроектировать примитивный тип, который сможет использоваться там, где нужно оперировать отрезком времени. И исходить нужно именно из такой постановки.
_FR> ...
_FR>От "взрослого" программиста я ожидаю умения решить, что ему нужно для решения задачи и реализации решения.
_FR> ...
_FR>Это всё надо вспомнить-представить себе при проектировании. То есть это правильные вопросы которые, как я ожидаю, подходящий в данном случае человек _себе_ задаст А дальше посмотрит на задание и найдёт ответы. Потом он покажет, что у него получилось…

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

Такие критерии достаточны для приёма студента, благо с него и спроса никакого нет, главное — уметь писать переиспользуемый код. Но раз уж собеседуем на сеньора, то нас в первую очередь должна интересовать способность человека вести часть проекта. Т.е. не делать на авось, а уметь самостоятельно разведать обстановку и принимать решения на основе объективной информации. Ну не будете же вы в реальной ситуации посередине итерации спрашивать:
"А почему это у нас нет ХХХ?"
или
"А зачем у нас добавилась ХХХ, когда горят сроки по YYY?"
Ответ "а вот тут я не получил указаний, поэтому сделал как показалось правильным" — это самое натуральное детство, потому что девелопер почти наверняка потратил время впустую, ради фана.

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

Здравствуйте, Sinix, Вы писали:

_FR>>Предметная область такая же, как им для типа DateTime нарпимер или даже Int32 То етсь _примитивный_ тип данных.

S>Интервалы — это не примитивный тип данных, это целый набор абстракций со своими правилами операций, логикой и холиварами (являются ли ±∞ допустимыми значениями числовой прямой, могут ли существовать интервалы вида (a,a], допустимо ли объединение непересекающихся интервалов и т.д. и т.п.). Аналогично — с работой с временем.

А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).

S>На мой взгляд, это неправильно. Если утрировать, то получается, что основной критерий приёма на работу следующий: человек должен решить задачу самостоятельно.

Конечно.

S>Если ему не хватает информации — он должен додумать её сам, не обращаясь к экспертам, за что потом и будет обстёбан

Вовсе нет. Ну какоё ещё информации не хватает, что бы сделать такое простое задание? Ну вы с ума что ли все посходили? То, что я прошу — каждый программист делает (или не делает) по сто раз на дню. То, что мне нужно должно обсуждаться на каждом кодеревью там где оно есть. Чесное слово. При написании абсолютного каждого типа данных. Вот вы сколько типов данных написали за прошедший месяц? Ну каких вы от меня подвохов ожидаете-то? Ну перечислите что ли, а то ну все поголовно как сговорились "слишком сложно, ничего не ясно, чего самим всё выдумывать" — а как спросишь "ну что выдумывать-то вам тут приходится такого сложного?" ни один не признаётся, прям партизаны Девушки в Смольном и то порешительнее были сто лет назад чем суровые програмисты с кучей лет опыта сегодня Принимать решения "это мы сделаем так, это вот так, а там будет этак" приходится повсеместно, буквально на каждом шагу. но многие об этом попросту не задумываются, не понимают, что если не обратить тут внимание на это то это выльется туда-то.

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

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

Здравствуйте, Donz, Вы писали:

D>Здравствуйте, _FRED_, Вы писали:

D> Но это не отменяет необходимости знать базовые вещи.
Меня всегда удивляло такое безаппеляционное утверждение про необходимость знать базовые вещи.
Это уже начинает напоминать религию "базовых вещей".

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

Здравствуйте, _FRED_, Вы писали:

_FR>А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).

Более чем применимо. Только холиварить неинтересно. Всё уже есть из коробки и обсуждение преимуществ-недостатков DateTime vs DateTimeOffset никакой практической пользы не принесёт. Но даже при наличии стандартной реализации иногда приходится пилить велосипеды. Джо Скит joda time не от скуки портировал

_FR>Вовсе нет. Ну какоё ещё информации не хватает, что бы сделать такое простое задание? Ну вы с ума что ли все посходили?
Того, что нужно получить на выходе Понятное дело, с одноразовым "написал и выбросил" проблем нет. А вот с библиотеками, тем более с публичным API...

При реализации интервалов есть несколько наборов сценариев, каждый из которых отсекает целую ветку вариантов реализации. Упрощённо:

1. Без требований: достаточно пары "begin-end" или "begin-duration" Обе реализации равноправны, но вторая имеет хороший задел для работы с продолжительностью (размер в часах, днях, месяцах и т.п.) и для описания абстрактных интервалов, без даты начала — год, месяц и т.п.

2. Нужно выполнять операции с интервалами — пересечение, объединение, расширение, проверка на входимость и т.п. Вариант с "begin-duration" отпадает из-за лишних накладных расходов.

3. Поддержка ±∞, типов границ (включительно-исключительно). Приходится вводить отдельную структуру для границ — передавать значение границы и тип границы отдельно сильно усложняет код.

4. Введение операций "получить дополнение интервала", "исключить интервал" — нужны составные интервалы с "дырками" внутри. Они порождают свой набор API, который не имел смысла до появления составных инетрвалов и кучу интересных дизайнерских проблем — например, стоит ли наследовать составной интервал от обычного? Оба варианта имеют далекоидущие последствия, если диапазоны активно используются в API.

5. Введение "ключей" диапазонов (значений, ассоциированных с отрезком) и быстрый поиск ключа в составном диапазоне на определённую дату.

Это я привёл только сценарии, которые требуют хранения интервалов как "begin-end". С begin-duration тоже есть свои заморочки, но они настолько редки, что затачивать под них кучу хелперов будет оверкиллом.

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

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

_FR>Я вот скажу — такой тип (или аналогичный) написать, то есть набрать в редакторе — ну минут пятнадцать — я не очень быстро печатаю.
Это будет прототип, а не готовая к реализации в продакшне идея. Если мы всё-таки собеседуем синьора, то способность написать компилируемый код по-моему не так важна, как умение предупреждать риски _до_ написания кода

_FR>В общем я похоже был прав, что написать визитор там какой-нить или веб-сервер современному программисту проще и понятнее, чем элементарную вещь Вернее, _взяться_ написать
Ну да Просто написать универсальную штуку, да ещё так, чтобы её было легко поддерживать, не ломая ничего у пользователей — это целое искусство. И на практике будет щастьем если соискатель сможет хотя бы прототип рабочий накидать, не говоря уже о том, чтобы назвать сильные-слабые стороны

Здравствуйте, msk78, Вы писали:

D>> Но это не отменяет необходимости знать базовые вещи.
M>Меня всегда удивляло такое безаппеляционное утверждение про необходимость знать базовые вещи.
M>Это уже начинает напоминать религию "базовых вещей".

M>Я вот, например, понятия не имею, как делают сахар, шоколадки Сникерс и Водку (могу только догадываться), но, тем не менее, не испытываю проблем с их употреблением.

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

M>Даже, если бы и знал я _базовые вещи_, то это только бы усилило мою вселенскую печаль и не более

Как обращаться и имеющимися знаниями — личное дело каждого

Здравствуйте, Sinix, Вы писали:

_FR>>А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).

S>Более чем применимо. Только холиварить неинтересно. Всё уже есть из коробки и обсуждение преимуществ-недостатков DateTime vs DateTimeOffset никакой практической пользы не принесёт. Но даже при наличии стандартной реализации иногда приходится пилить велосипеды. Джо Скит joda time не от скуки портировал

Не переводите тему разговора. Мои слова и ваши, на которые я отвечал (и которые вы направсно убрали из цитаты) были совсем не о том, что вы тут начали о "DateTime vs DateTimeOffset" и т.п. Если вы будете так быстро терять нить диалога и перескакивать с сути на что-то побочное,Ю то лучше и не продожать.

_FR>>Вовсе нет. Ну какоё ещё информации не хватает, что бы сделать такое простое задание? Ну вы с ума что ли все посходили?
S>Того, что нужно получить на выходе Понятное дело, с одноразовым "написал и выбросил" проблем нет. А вот с библиотеками, тем более с публичным API...

То, что нужно сказано в самом начале А придираться типа "купи слоника", то есть до бесконечности выяснять что-то, умеет любой ребёнок. Надо же всё-тки где-то совесть иметь и не стоит спрашивтаь тут одно и то же столько раз. Если после всего то что я наотвечал вма и другим в этом топике вам не достаточно что бы сделать что попросили — то продолжать конечно бесмысленно. Собеседование как правило длится два-три часа максимум. Если такую простую задачу я должен объяснять вам несколдько часов — то вы мне не нужны.

S>При реализации интервалов есть несколько наборов сценариев, каждый из которых отсекает целую ветку вариантов реализации.

Я знаю. Ну и что. То же самое можно сказать про DateTime. Вы не заметили что ни разу на мой вопрос в нашей дискуссии не ответили? Ещё раз повторю — Те же яйца есть и с типом DateTime — "несколько наборов сценариев". Однако тип существует. Он написан. Если вы этого не понимаете, то избавьте уж а? Дальше даже не читал, ибо бесполезно — я вам много уже написал, но у меня такое впечатление, что и вы не читаете.

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

Здравствуйте, _FRED_, Вы писали:

_FR>Суть задачи была в следующем: требовалось спроектировать элементарный, простейший, практически примитивный тип данных самого "широкого профиля" (как будто он будет добавлен в mscorlib на ровне с Int32, String, DateTime и т.п.). Например, тип данных, который представляет из себя отрезок времени между двумя датами (двумя точками на временной оси). По большому счёту, даже код показывать не нужно, достаточно рассказать, каким этот тип должен быть — что в нём было бы полезно учесть, что нужно было бы сделать, что не нужно.

Надоело мне тут ерундой заниматься, пытаясь объяснить самые простые вещи. Мне было интересно-то всего выяснить всего ничего:

[Serializable]
[DebuggerDisplay("{From} - {To}")]
public struct DateTimeInterval : IFormattable, IEquatable<DateTimeInterval>
{
  static DateTimeInterval() {
    Empty = default(DateTimeInterval);
  }

  public DateTimeInterval(DateTime from, DateTime to) : this() {
    // Проверка, что каинды совместимы
    // Проверка, что to >= from или как-то ещё, главное что бы билось со всем остальным
  }

  public DateTimeInterval(DateTime from, TimeSpan duration) : this(from, from + duration) { }

  public static DateTimeInterval Empty { get; private set; }

  public DateTime From { get; private set; }
  public DateTime To { get; private set; }
  public TimeSpan Duration { [DebuggerStepThrought] get { return From - To; } }

  public static DateTimeInterval Create(DateTime item1, DateTime item2) {
    /* создание валидного интервала от минимального к максимальному, если в кторе проверка */
  }

  // Метод Parse в противовес ToString

  override // всего что есть от Object + реализация интерфейсов + операторы == и !=

  // операторы сложения-вычитания с TimeSpan и соответствующие методы Add/Substruct
}

Ну вот например. Обратил бы внимание, что выбран value type, что он неизменяем, что реализованы "стандартные" интерфейсы, которые в праве ожидать от такого типа любой программист (знающий о них). Не забыли о сериализации — нам ни капельки не cложно, а вот забудь мы — пользоватли нас помянут не раз злым словом. Подсобили отладчику. Завели Empty — весьма полезная весчь. А IComparable изобразить смогли бы? А как и почему?

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

Всё это, мне кажется, должно быть на уровне подсознания. Тут ничегошеньки страшного нет. Всё, что мне не понравится или вызовет вопросы — я обязательно спрошу. Забыть чего-то нельзя. Набирать текст оказалось дольше чем рассказывать на самом деле. Где тут переусложнизм? где тут что не ясного? Я ни чудес, ни догадывания того, чего я загадал не ждал. А получил то что хотел. Этот тип не есть белая ворона среди других примитивных типов. А класс с двумя паблик полями, что показывали выше, будет таким уродцем. Если бы в нём заменить поля на автосвойства он ещё подошёл бы как DTO, но я не это просил.

Ну хотите открытые интервалы? ну делайте свойства nullable или скажите, что для таких вещей лучше другой тип написать. Методы а-ля Intersect/Intersects и т.п. (а какие сами могли бы придумать?) не обязательно тут иметь, их можно сделать extension-ами. Ну захотелось бы мне, попросил бы Intersects изобразить. Хотите вместо DateTime использовать новый DateTimeoffset? Да кто ж вам запретит? Не придётся заморачиваться с каиндом. а взяли DateTime, то заморочиться хорошо бы. Дабы пользователя оградить от возможной ошибки. А как бы именно заморочились?

А что за дырки в интервалах? Вы задание внимательно прочитали? "отрезок времени между двумя датами". При чём здесь дырки? Может, ещё и бозон интервала какой-нить выдумаем? А бесконечность? Не перевирайте задание пожалуйста! я сказал две точки на оси. Ну какая бесконечность? Зачем вы переусложнизмом занимаетесь? А хотите бесконечность? Ну и тут на самом деле можно выкрутиться. Только этого я не просил. Я, как вы можете видеть, не ожидаю вообще ничего такого, о чём не сказал бы. Все эти сериализации\иммутабельности — не потому что я их придумал, а потому, что платформа на которой вы работаете располагает к этому. Посмотрите на все остальные примитивные типы и покажите мне мутабельный. Ага? У них есть всё то, что тут. Неужели не каждый опытный, взрослый программист должен с этим справиться? А не каждый ли новичёк сумеет это сделать, проситав несколько книг и официальные рекомендации?

Здравствуйте, _FRED_, Вы писали:

_FR>Ну хотите открытые интервалы? ну делайте свойства nullable или скажите, что для таких вещей лучше другой тип написать.

nullable всё-таки не подойдёт конечно это скорее если бесконечность нужна, так что лучше другой тип написать. В любом случае, если дата сметри 1 января 2000 — это включительно? А если период жизни 1 января 1900 — 1 января 2000 — тут тоже очевидно что всё включительно? В общем, не принципиально, если бы была важна включительность — я бы конечно сказал. А так всё что угодно подошло бы, лишь бы билось с остальным.

Здравствуйте, msk78, Вы писали:

D>> Но это не отменяет необходимости знать базовые вещи.
M>Меня всегда удивляло такое безаппеляционное утверждение про необходимость знать базовые вещи.
M>Это уже начинает напоминать религию "базовых вещей".

Способность читать и писать тоже религией назовешь?

M>Я вот, например, понятия не имею, как делают сахар, шоколадки Сникерс и Водку (могу только догадываться), но, тем не менее, не испытываю проблем с их употреблением.

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

M>Даже, если бы и знал я _базовые вещи_, то это только бы усилило мою вселенскую печаль и не более

Меня вселенская печаль настигает, когда я вижу сравнение строк через ==, слышу о реализации метода hashCode через ГСЧ, читаю данные мониторинга за десять минут, в котором общее ожидание нитей составляет около получаса.

Здравствуйте, _FRED_, Вы писали:

Что-то мы вообще не о том начали спорить Давайте вот так:

Я считаю, что если мы берём человека на должность сеньора, то нам должно быть в первую очередь интересно, как он решает задачи с практически применимым выхлопом. Знание FDG/умение следовать стандартным гадлайнам привить куда проще, особенно при нормальном процессе разработки — с автоматизированными проверками при билде, тестами и design review.

Конечно, я могу быть неправ и вы ожидаете от сеньора совсем других наборов скиллов, например вам куда важнее, чтобы человек умел сам решать задачи при неизвестных вводных. Мне реально интересен ваш взгляд на то, что стоит проверять на собеседовании, а что нет. Если мои ответы выглядят как возражения ради возражений — напишите, попробую исправиться:0

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

---

_FR>Не переводите тему разговора. Мои слова и ваши, на которые я отвечал (и которые вы направсно убрали из цитаты) были совсем не о том, что вы тут начали о "DateTime vs DateTimeOffset" и т.п. Если вы будете так быстро терять нить диалога и перескакивать с сути на что-то побочное,Ю то лучше и не продожать.

Ок, контекст целиком:

_FR>>>>Предметная область такая же, как им для типа DateTime нарпимер или даже Int32 То етсь _примитивный_ тип данных.
S>>>Интервалы — это не примитивный тип данных, это целый набор абстракций со своими правилами операций, логикой и холиварами [примеры холивара skippped]
_FR>>А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).
S>>Более чем применимо. Только холиварить неинтересно. Всё уже есть из коробки [примеры аналогичных холиваров skippped] никакой практической пользы не принесёт. Но даже при наличии стандартной реализации иногда приходится пилить велосипеды [пример, когда стандартного примитива недостаточно и приходится пилить свой skipped]

Не, серьёзно, где я перевожу тему?

_FR>То, что нужно сказано в самом начале А придираться типа "купи слоника", то есть до бесконечности выяснять что-то, умеет любой ребёнок.
Ну блиин... здравую логику никто не отменял. Зачем нам сеньор, который просит построчной спецификации? Ещё раз, речь с самого начала шла про то, что если задание допускает несколько принципиально разных толкований, то человек с опытом не должен бросаться на баррикады и пилить код так, как он видит. Для начала неплохо бы уточнить в какую именно сторону бросаться Это уточнение займёт максимум минут пять-семь, сэкономит гораздо больше.

Если человек в ответ на "что конкретно вам нужно?" получает "это ж очевидно — примитив уровня datetime", то он и сделает сфероконя так как его понимает. Раз уж передаёте человеку ответственность за кусок кода, так убедитесь, что он понял задачу так, как её видите вы.

_FR>Я знаю. Ну и что. То же самое можно сказать про DateTime. ... Те же яйца есть и с типом DateTime — "несколько наборов сценариев". Однако тип существует.
Угу, и раз он написан, то уточнять как его написать — несколько бессмысленно, не находите? У нас с вами другая ситуация: вы просите "напиши класс для работы с числами с запятой", а на вопрос "какие граничные условия?" отвечаете "а посмотри как в Int32 всё организовано". По сути человеку отталкиваться не отчего, вне зависимости от того, что он напишет — float/decimal или BigRational — он всё равно может оказаться неправ.

Аналогично — с DateTime. Если его писать с 0, то на выходе может получиться "стандартный" DateTime или DateTimeOffset или классы из Joda. Но нам скорее всего была нужна какая-то конкретная реализация. Зачем просить "сделай как знаешь", если результатом с определённой долей вероятности будет нельзя пользоваться?

_FR>Надоело мне тут ерундой заниматься, пытаясь объяснить самые простые вещи. Мне было интересно-то всего выяснить всего ничего:
Блин! Это не

элементарный, простейший, практически примитивный тип данных самого "широкого профиля" (как будто он будет добавлен в mscorlib на ровне с Int32, String, DateTime и т.п.). Например, тип данных, который представляет из себя отрезок времени между двумя датами (двумя точками на временной оси)

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

Например, только одна операция "получить дополнение интервала [0, 10]" (числа/даты — здесь не так уж и важно) — это сразу и введение типов границ (открытая/закрытая), и +/- бесконечность, и составных интервалов. Иначе результат — { (-∞,0), (10, +∞) } — не отобразить никак. Без дополнения у вас отпадает целый класс операций — например, исключение одного интервала из другого. А с тем заделом, что пришлось ввести для операции дополнения практически нахаляву становится доступен целый ряд весьма интересных операций — например, получить все пересечения в некотором наборе интервалов. Это нужно, когда у вас есть несколько независимых наборов хроникальных записей и вы хотите что-то посчитать на каждый из отрезков времени.

Самый простой пример: у человека оклад с 1 по 10е — 100 рублей, с 10 по 31е — 200. Надбавка — 1 по 15е — 10%, с 20 по 31е — 5%. Как насчёт быстро посчитать какие суммы следует выдавать в течение всего месяца?

Вот это сценарий для типа "широкого профиля", который может быть включён в стандартную библиотеку для платформы. Если ограничиться заглушкой, то она будет использована только для случая когда надо передать куда-нибудь уже вычисленный промежуток. Для дальнейших вычислений пользователям всё равно придётся лепить свои костыли. И зачем нужен такой тип данных?

Синдром Not Invented Here. Писать свой интервал дат — это пустая трата денег. В С# отличные средства работы с датами, если не хватает — полно третьих библиотек. Сначала Дату свою напишем, потом свой XML парсер, потом свою библиотеку шаблонов. Вот например mail.ru свою базу данных ключ/значение написали — пусть плохо документированная, пусть отстала от того-же редиса по функционалу и кучеству — но мы же ее сами написали и так любим!

Здравствуйте, Sinix, Вы писали:

_FR>>Не переводите тему разговора. Мои слова и ваши, на которые я отвечал (и которые вы направсно убрали из цитаты) были совсем не о том, что вы тут начали о "DateTime vs DateTimeOffset" и т.п. Если вы будете так быстро терять нить диалога и перескакивать с сути на что-то побочное,Ю то лучше и не продожать.
S>
S>Ок, контекст целиком:
S>

_FR>>>>>Предметная область такая же, как им для типа DateTime нарпимер или даже Int32 То етсь _примитивный_ тип данных.
S>>>>Интервалы — это не примитивный тип данных, это целый набор абстракций со своими правилами операций, логикой и холиварами [примеры холивара skippped]
_FR>>>А разве к простому типу DateTime тоже самое не применимо? Ха! Ещё как. Ещё какой набор абстракций, ещё сколько правил и логики (даже больше чем надо, но не в этом суть).
S>>>Более чем применимо. Только холиварить неинтересно. Всё уже есть из коробки [примеры аналогичных холиваров skippped] никакой практической пользы не принесёт. Но даже при наличии стандартной реализации иногда приходится пилить велосипеды [пример, когда стандартного примитива недостаточно и приходится пилить свой skipped]

S>Не, серьёзно, где я перевожу тему?

Ну так давайте разберём. Перечитайте пожалуйста очень внимательно процитированное. Из того, что вы сами сказали, что "Более чем применимо" вытекает, что и DateTime — "это не примитивный тип данных", ибо по вашим же словам "это целый набор абстракций со своими правилами операций, логикой и холиварами". Нет, он примитивный. Ибо очень простой. Это тот самый гвоздь, который сотни тысяч наших коллег-программистов используют достаточно регулярно. В этом суть абзаца. А не в том, о чём вы стали говорить далее: прохоливары и прочее.

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

S>Аналогично — с DateTime. Если его писать с 0, то на выходе может получиться "стандартный" DateTime или DateTimeOffset или классы из Joda. Но нам скорее всего была нужна какая-то конкретная реализация. Зачем просить "сделай как знаешь", если результатом с определённой долей вероятности будет нельзя пользоваться?

То, можно ли будет пользоваться, зависит только от вас. И не "как знаешь", а "как посчитаешь нужным" — это две большие разницы. Попробуйте их уловить. Вы как раз пытаетесь сделать всё, что знаете и естественно у вас много вопросов. Попробуйте сами ответить на них. Это между прочим тоже на собеседовании заметно: когда по отдельности спрашиваешь (ну как везде) про разницу между struct/class и т.п. все конечно отвечают. А когда сами что-=то делают, почему-то этими знаниями не пользуются! Поэтому я решил не специально спрашивать, а дать возможность сделать и поазать, что умеешь использовать то, что знаешь. Задача толлько для этого.

S>это "заглушка" для представления информации о промежутке времени. Да, она классно написана, не имеет косяков в дизайне, но она абсолютно непригодна для работы с промежутками времени. Последнее требует наличия операций, минимум — пересечение, объединение, получение дополнения интервалов. А поскольку арифметика должна быть замкнутой, то результатом всех трёх вышеперечисленных операций тоже должны быть промежутки.

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

S>Например, только одна операция "получить дополнение интервала …

А кто вам сказал, что эта операция _необходима_? Вы вот придумали задачу с дополнением, но решить не смогли. А я смог. Так как в условии о необходимости небыло ничего сказано, я _не обязан_ добавлять эту возможность. Я принял решение, что данном случае возможность получить дополнение излишне перегружает дизайн. Всё. Точно так же разработчики DateTime приняли, что представить с помощью их типа какие-то фантастические даты из запредельного будущего или наоборот шибко исторические даты из истории Древней Греции будет нельзя. И миллиардные доли секунды нельзя описать с помощью этого типа. Всё проектирование — это всегда выбор и принятие решений. Обратите внимание, я все вопросы проецирую на то, что уже сделано и к чему по условию мне нужно максимально приблизиться, и нахожу ответы там. И прежде чем придумать новый вопрос — постарайтесь сами найти для него ответ этим же путём.

S>Самый простой пример: у человека оклад с 1 по 10е — 100 рублей, с 10 по 31е — 200. Надбавка — 1 по 15е — 10%, с 20 по 31е — 5%. Как насчёт быстро посчитать какие суммы следует выдавать в течение всего месяца?
S>Вот это сценарий для типа "широкого профиля", который может быть включён в стандартную библиотеку для платформы. Если ограничиться заглушкой, то она будет использована только для случая когда надо передать куда-нибудь уже вычисленный промежуток. Для дальнейших вычислений пользователям всё равно придётся лепить свои костыли. И зачем нужен такой тип данных?

"широкий профиль" — это не "всё-всё-всё на свете". Даже универсальный ключ подходит не ко всем замкам, а только ко всем замкам определённой серии или модели. Типом Int32 тоже нельзя описать всевозможные числа, есть Int64 и даже BigInt — не один какой-то тип данных, а несколько, каждый на свой случай. Я не в первый раз вам говорю, что не требую чего-то, что покрывает все кейсы. Вы на это-то почему-то упорно внимания не обращаете и пишите так много вопросов

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

Здравствуйте, Handie, Вы писали:

H>В С# отличные средства работы с датами,

"Ха-ха", как говорит кто-то из Симпсонов.

H>если не хватает — полно третьих библиотек. Сначала Дату свою напишем, потом свой XML парсер, потом свою библиотеку шаблонов.

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

Здравствуйте, _FRED_, Вы писали:

_FR>Ну так давайте разберём. Перечитайте пожалуйста очень внимательно процитированное. Из того, что вы сами сказали, что "Более чем применимо" вытекает, что и DateTime — "это не примитивный тип данных", ибо по вашим же словам "это целый набор абстракций со своими правилами операций, логикой и холиварами". Нет, он примитивный. Ибо очень простой. Это тот самый гвоздь, который сотни тысяч наших коллег-программистов используют достаточно регулярно. В этом суть абзаца. А не в том, о чём вы стали говорить далее: прохоливары и прочее.

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

Тогда да, я мягко говоря промахнулся с возражениями

_FR>То, можно ли будет пользоваться, зависит только от вас. И не "как знаешь", а "как посчитаешь нужным" — это две большие разницы. ... Это между прочим тоже на собеседовании заметно: когда по отдельности спрашиваешь (ну как везде) про разницу между struct/class и т.п. все конечно отвечают. А когда сами что-=то делают, почему-то этими знаниями не пользуются!
Ок, уловил идею.

S>>это "заглушка" для представления информации о промежутке времени. Да, она классно написана, не имеет косяков в дизайне, но она абсолютно непригодна для работы с промежутками времени. Последнее требует наличия операций, минимум — пересечение, объединение, получение дополнения интервалов. А поскольку арифметика должна быть замкнутой, то результатом всех трёх вышеперечисленных операций тоже должны быть промежутки.

_FR>Не понимаю что значит в данном месте "заглушка" и почему она "непригодна".
Я исходил из того, что нужно сделать тип данных, который позволяет производить все типовые операции с отрезками без введения дополнительных сущностей — как int достаточно для построения замкнутой арифметики для работы с целыми числами. По сути, обсуждать правильность/неправильность проектирования вашего примера — это всё равно что обсуждать внутреннее устройство decimal-а, написанного без учёта необходимости складывать-вычитать А как только мы полезем в такие дебри, тут же окажется, что весь набросанный код летит к чертям, потому что без введения дополнительных абстракция пользоваться нашим отрезком будет неудобно.

S>>Например, только одна операция "получить дополнение интервала …
_FR>А кто вам сказал, что эта операция _необходима_?
Никто, но без неё набор операций с интервалами получается незамкнутым и в целом наборе сценариев отрезком пользоваться будет нельзя. Это всё равно, как если бы авторы int-а решили бы что унарный оператор минус и вычитание излишне перегружают дизайн.

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

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

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

Здравствуйте, _FRED_, Вы писали:

_FR>Во время собеседования интересно выявить у кандидата умение использовать имеющиеся знания и навыки. По-моему, то, на сколько человек умеет пользоваться тем, что знает гораздо важнее (в профессиональном плане и долгосрочной перспективе) …широты, так сказать, знаний, которые "лежат без дела" (или используются не по назначению, что суть одно и то же). Позиция, конечно, спорная (велкам).

Пинаю. Ужасно.
Проблема в целеполагании. Совершенно непонятно, что вы желаете получить. Что должно быть на выходе от кандидата (ну кроме холивара на счёт интервалов, представления дат и т.д.) и что должно быть на выходе от выполнения теста (какие качества этот тест проверяет).

В итоге имеем "угадай, что я хочу а я угадаю, что ты умеешь". Смысл данного действа от меня ускользает.