Кстати, да. Я совсем забыл про это! Я ж на втором курсе был в стройотряде летом. Спал суперски, с десяти до восьми. Правда, мы и херачили, простите, на работе адово. Тут главное будет лень перебороть.
Ну, когда я говорю людям, что я сова, многие воспринимают это как попытку оправдаться.
Кстати, я выдумал (не утверждаю, что первый)) такой приём: во время отпуска каждый день ложиться на час позже с тем, чтобы и вставать на полчаса позже утром. Примерно такой график сна ожидался:
1й день: 01:00 — 10:00,
2й день: 02:00 — 11:00,
3й день: 03:00 — 12:00 и т.д.
Расчёт тут на то, что время начала сна должно плавно перескочить через день, снова прийти на вечер, т.е. на то время, когда ложатся спать нормальные люди. Разумеется, не сработало. После пятого дня чувствовал себя марсианином (к тому же не выспавшимся).
Я честно пробовал так поступать. Только это не работало. Правда, я пришёл к выводу, что надо снова применить метод. Может что-то поменялось с того времени.
По большому счёту, я не согласен тут только с поздним приходом на работу. Я поздно прихожу, только потому что поздно встаю, потому что имею некоторые проблемы со сном (хронически не высыпаюсь). Так что с загруженностью это совсем не обязательно связано.
В остальном автор близок к истине. Спасибо за перевод!
Да, костыль и очень уж неприятный. Пробовал реализовать неявное приведение, но это удалось сделать только в одну сторону (из HidingProperty в T). Да даже если реализовал бы, это было бы не очень хорошо. У implicit cast операторов есть свои проблемы с использованием, насколько я знаю.
Так может тогда есть смысл закрыть тему, чтобы люди не читали моей ереси?
Если имеется в виду противный интерфейс с мерзкими Get(), Set(), то я согласен. В противном случае (поддержка на уровне языка), всё было бы абсолютно прозрачно.
По сути, мой подход тоже тру-ООП. HidingProperty это фактически мини-класс, берущий на себя ответственность за правила обращения к полю. Если эти правила тривиальны как в описанном случае, то я не вижу большого прироста сложности. Таким образом, HidingProperty инкапсулирует микрослой знаний о типе данных Speed в данном примере. Раз уж из всех особенностей этого типа мы имеем только ограничение на геттер и сеттер, то чем плохо декларировать этот тип по месту его единственного использования? Если бы ещё и синтаксис был таким как его предложил мой коллега, то всё вообще выглядело совсем естественно. Поправьте, если не так.
Этого часто недостаточно. Одно дело, когда есть такой сервис, который сохраняет и имеет валидатор. И совсем другое, когда объект сконструирован и может/должен быть сразу применён согласно какой-то логике. Мне очень нравится, когда есть возможность иметь какие-то возможности «автоматически», без лишних телодвижений.
Как я уже сказал, в идеале полное сокрытие должно быть реализовано в самом языке C#.
Во-первых, о таком даже не подумал. Во-вторых, я не очень люблю игры с директивами, честно говоря. Да и threat warnings as errors не всегда, подходят, хотя я сам двумя руками ЗА такую практику.
В остальном же, решение подкупает своей простотой. Довольно изящно.
Да, все люди разные. Отчасти я стараюсь как можно больше полагаться компилятор, из-за своей плохой памяти. В любом случае, спасибо за оценку. Мнение со стороны полезно.
Да, я сперва совсем не так понял. Спасибо за разъяснение.
Интересный вариант. С ходу из недостатков вижу только намеренно бессмысленное именование, которое планируется использовать как достоинство. Ну и нет, к сожалению, защиты от того, что кто-то всё-таки напишет по ошибке ___backingField2 = someWrongValue; Прямой доступ всё-таки останется. Хотя в хорошей, дисциплинированной команде такая ситуация практически исключена.
Мне не нравится решение в стиле «запомнить». Это легко забыть. И если вы (я или Вася Муркин) вдруг таки забыл, что есть свойство и будет использовать поле, компилятор не скажет ему ай-яй-яй. Кстати, отсутствие подобного рода проверок — единственное, что мне не нравится в интерпретируемых языках.
Пункт б) я перечитал несколько раз и не понял его, простите.
Кстати, я выдумал (не утверждаю, что первый)) такой приём: во время отпуска каждый день ложиться на час позже с тем, чтобы и вставать на полчаса позже утром. Примерно такой график сна ожидался:
1й день: 01:00 — 10:00,
2й день: 02:00 — 11:00,
3й день: 03:00 — 12:00 и т.д.
Расчёт тут на то, что время начала сна должно плавно перескочить через день, снова прийти на вечер, т.е. на то время, когда ложатся спать нормальные люди. Разумеется, не сработало. После пятого дня чувствовал себя марсианином (к тому же не выспавшимся).
В остальном автор близок к истине. Спасибо за перевод!
Так может тогда есть смысл закрыть тему, чтобы люди не читали моей ереси?
Как я уже сказал, в идеале полное сокрытие должно быть реализовано в самом языке C#.
В остальном же, решение подкупает своей простотой. Довольно изящно.
Интересный вариант. С ходу из недостатков вижу только намеренно бессмысленное именование, которое планируется использовать как достоинство. Ну и нет, к сожалению, защиты от того, что кто-то всё-таки напишет по ошибке ___backingField2 = someWrongValue; Прямой доступ всё-таки останется. Хотя в хорошей, дисциплинированной команде такая ситуация практически исключена.
Пункт б) я перечитал несколько раз и не понял его, простите.