Трудность возникает, если клиентам будет позволено менять значение зависимости в течение жизненного цикла класса.
Вы запретили клиентам вызывать сеттер более одного раза, но между вызовом конструктора и вызовом сеттера есть промежуток времени, в течении которого значения будет «изменено» со значения по умолчанию на новое. Особенно мне не нравится установка дефолтового значения в геттере. Почему яно не использовать Lazy?
Property-injection используется для необязательной зависимости и в зависимости от того, что делает дефолтовая реализация, может даже имеет смысл делать null-проверки в коде локально, каждый раз при обращении к экземпляру. Всегда имплементировать реализацию, которая «ничего не делает» — как-то накладно.
По-моему лучше необязательную injection делать через оверлоад конструктора, для property-injection требуется, чтобы зависимость обладала «некими» специфическими свойствами, к примеру, чтобы уже существовала дефолтовая имплементация, которая позволит избежать спагетти-кода из-за null-проверок.
придется либо делать свойство только для записи (set-only property), что противоречит общепринятым принципам проектирования на платформе .NET
Каким таким «общепринятым» принципам? Есть guidelines, где написано "X DO NOT provide set-only properties"
Спасибо за ответ. Действительно литералы так «красивше».
А про сигнатуру метода все равно не понял, но я и раньше не особо-то использовал именованные параметры, скажем, исключительно если много из них со значенями по умолчанию (в конце списка параметров) и мне хочется только один передать:
MyMessageBox("Bla", "Error", icon: Icon.Error);
Уж получше чем указывать значения, равные тем, что по-умолчанию, для всех предыдущих параметров:
В чем именно «соль» использования параметров без имени после именованых — не понятно. В вашем примере первый вариант самый правильный. Посмотреть сигнатуру метода (если нужно) можно простым мышконаведением в нормальной IDE, а каждый раз писать второй вариант — перебор.
Почему 7.2 (а не скажем 8)? Где ссылки на первоисточник инфы? Как по мне — не до конца разжевано, многое остается «за кадром», не уверен, что мое «додумывание» верно.
Например, именование параметров при вызове возможно необходимо, чтобы при рефакторинге получить ошибки по всех вызовах где позиция не совпадет? А зачем?
Про подчеркивание не понял вообще, что за проблему решили.
Программирование — это процесс написания алгоритма. Алгоритм — это «упрощенная» логика, решающая определенную задачу в определенных условиях. Не пойму, каким образом специализированный обьект Interval, способный хранить 2 даты и сравнивать себя с другими обьектами (включая другие типы, например Date) вдруг становится вселенской нерешаемой проблемой, с континуумом, веществом и т.д.
Вы, скорее всего, решаете какую-то определенную задачу, и потому вам, возможно, потребуется другой обьект, не Interval. Но я так и не смог понять, для решения какой задачи нужно зачему-то разбивать интервал на континуумы и хранить их.
И не хватает выводов, что с того, что Interval такой, а не другой (который вам нужен)? Чем такое моделирование плохо?
Часто для наследования в ООП приводят контрпример отношений между квадратом и прямоугольником
Часто это в смысле «никогда»? Взяли неудачный пример и что? Пусть скажем ну них базовый клас Figure. Очень удобно иметь возможность обьявить некий List и пройтись по нему вызывая виртуальный метод Draw. При добавлении новой фигуры код менять не надо. Вот это круто. Вот это «частый» пример.
Помните о правиле трех секунд: то, что продержалось в Сети хотя бы три секунды, — заскринено, скопировано и уже распространено
Правило сами придумали? Что значит «продержалось»? Поиск выдает баскетбольное правило и с десяток выдуманных правил: при знакомстве, в каких-то настольных играх и тд.
Интересно. Транзакция? Что если произойдет сбой после отрисовки кольца и до того, как исходное удалено? На экране будет 2 кольца. Вы об этом не подумали?
Вообще я заметил, что нам (программистам) свойственно «додумывать» различные условия и крайности. Это хорошо видно на stackoverflow, когда плохо сформулированные вопросы неожиданно получают несколько ответов, решающих разные проблемы.
В вашем случае, выбрав Б, вы «додумываете» некую «сохранностить данных». В моем случае, выбирая А (см. мой комментарий ниже), я «додумываю» некую синхронность отрисовки, типа кольцо сначала должно быть убрано, а уже потом добавлено.
Хорошее вступление… Последнее предложение — кто это «мы»? Я? Я вообще не понял смысла. Вы ввели определенные ограничения в «вашу игру» — даны 2 команды и поставили задачу с помощью их нарисовать что-то. Круто! И?
«Сильный» программист просто знает правильный порядок, допустим, если бы были задержки при синхронной отрисовке или анимации, то правильный порядок был бы «убрать кольцо с 1» (требует 2 команды, из-за того, что прямоугольники накладываются друг на друга оптимальный порядок единственный) и «добавить кольцо к 2», т.к. тогда кольцо сначало было бы убрано, а потом надето, как в реальности. Несмотря на то, что вы добавили условие «нет анимаций» именно этот путь наиболее «логичный».
Последняя программа тоже логична, она просто сперва очищает экран, а потом рисует то состояние, которое нужно. Это может быть более оптимальный путь, если ввести несколько уровней абстракции, к примеру, добавить очередь/список команд, при изменение которого потребуется перерисовка, перед которой экран всегда будет очищаеться. Повысится читаемость, модифицируемость и поддерживаемость программы за счет производительности. Что лучше — зависит…
Вообще понять мысли разглядывая код написанный другим, если только он не намного ниже вашего уровня мышления/программирование, это сложная задача. Комментарии и использование стандарных паттернов/именований облегчает задачу.
Мне кажется, в статье хорошо освещена проблема (мне сложно представить мысли человека, выбравшего В или С). А вот анализа и решения (что с этим делать) — увы нет.
Прочел до конца, ожидая когда же начнут рассказывать про Netflix, но это оказалось всего-лишь уткой. Про Wallmart слышал и скорее всего прочел бы и без утки. Но сейчас так модно да?
Статья — это очередное «видение» идеала, которое возможно придется менять после следующего увольнения.
Мне интересно кто берет в штат людей, меняющих фирмы как носки? И на что они расчитывают? Я б не взял. Смысл? Уйдет ведь, с высокой вероятностью…
Скорее всего проблема в авторе, а не в окружающем мире. Книжки читать полезно, но возможно нужна помощь специалиста? Неужели комментарии с минусами ни о чем не говорят?
История о неудачах другим была бы полезной. А учить как надо — пожалуй не стоит…
Вот только статей с конкурсами и плясками (кодэгольфами) на хабре как раз и не хватает /sarcasm.
Конкурс в кавычках, потому что это никакой не конкурс, я правильно понимаю? Или есть жюри и призы? Автору просто захотелось запостить свой код, возможно весьма крутой (не владею питоном), но это не делает его хоть чуточку полезнее.
Предыдущая статья тоже «ни о чем», впрочем там хоть какой-то смысл был, а здесь? 15 скриншотов это статья?
Жду с нетерпением следущую статью, боюсь даже предположить, о чем (и да /sarcasm).
Читают 2–3 статьи, в каждой из которых по 5–10 советов.
На 100% максимально совершенно абсолютно надежный способ
Ситуация: есть 3 статьи с советами. Три? Абсурд! Нужно написать одну, клевую, чтобы другие можно было не читать! Ситуация: есть 4 статьи с советами. Оригинал
Тоесть вы действительно считаете, что это хорошая статья? Почему?
Или вы не в теме (не веб разработчик) и по лайкам там решили, что тема достойная для хабра?
Прямо хочется, чтобы для любого перевода был обязательный абзац «Почему я это перевел». Уже ее первый раз вижу, когда треш (а это именно треш, мусор, популистская статья, бессмысленная и бесполезная) переводят и публикуют тут. Не понимаю в расчете на что? С одной стороны усилия потрачены (на перевод), перевод вроде не плохой (читается легко), а с другой — блин, ну зачем? На какую аудиторию рассчитана статья?
WPF и его Data Binding много чего странного привносит в архитектуру решения
В точку.
свойства не должны содержать никакой логики.
Судя по всему, вы путаете назначение полей и свойств. Свойства как раз для того и нужны, чтобы добавить некую «простую» логику, чего нельзя сделать для поля. Интуитивно я понимаю, что вы имели в виду. Если эта логика переиспользуется или слишком сложна (много строк или различающихся по смыслу действий?) для свойства, то ее имеет смысл вынести в отдельный (переиспользуемый) метод или даже в несколько.
В вашем примере, если Name — это свойство, при установке которого должны установится другие, то вполне ожидаемо получить исключение при ошибке парсинга или конвертации. Например, FullName может ожидать пробел и/или более одного слова, чтобы установить FirstName и LastName.
Я примерно так же позволяю себе чатиться с коллегами. Вам не кажется, что для статьи (которую будут читать незнакомые вам люди) это через чур уж жаргонно?
Не критикую ни капли, просто задумался, например, напиши вы такое в комментах — я бы и не заметил, а в статье почему-то «задевает». То ли «призма авторитета», то ли ощущение «успешного человеа» (зависть?), не пойму в чем дело.
Почему это? ExceptionValidationRule в WPF специально для этого и существует. Чем getter/setter cвойств принципиально отличаются от методов, в которых, я надеюсь, исключения не зло?
Взяли 50-летнего прагматика и 20-летнего энергичного студента, одного назвали профессионалом, второго — любителем и понеслась…
В статье вообще, от слова полностью, не раскрывается тема. Так, на поржать. А тема вообще-то серьезная. Может стоило бы хотя бы сменить название на шутливое? А то вон веб-разработчики (хирурги интернета) со своей спецификой работы приняли это слишком близко к сердцу выше ;)
С одной стороны, разница между профессионалом и любителем очевидна. С другой — поделить людей на 2 группы, белых и черных, не выйдет. Вы предлагаете нанимать любителей, это как вообще делается? «Фирма ищет любителей, профессионалам не беспокоится»? Аналогично с профессионалами, при найме на работе, какой критерий использовать, после которого человек вдруг из любителя становится профессионалом? Спрашивать: «Вы уходите домой ровно в 17:00»?
Странно, почему автор, желая поговорить об NLP не начал с каменного века, там порядком интересного произошло до выхода виндоус 98, совершенно не имеющего отношения к NLP.
А когда до NLP добрался, выдохся что-ли? Или будет следующая статья?
Property-injection используется для необязательной зависимости и в зависимости от того, что делает дефолтовая реализация, может даже имеет смысл делать null-проверки в коде локально, каждый раз при обращении к экземпляру. Всегда имплементировать реализацию, которая «ничего не делает» — как-то накладно.
По-моему лучше необязательную injection делать через оверлоад конструктора, для property-injection требуется, чтобы зависимость обладала «некими» специфическими свойствами, к примеру, чтобы уже существовала дефолтовая имплементация, которая позволит избежать спагетти-кода из-за null-проверок.
Каким таким «общепринятым» принципам? Есть guidelines, где написано "X DO NOT provide set-only properties"
А про сигнатуру метода все равно не понял, но я и раньше не особо-то использовал именованные параметры, скажем, исключительно если много из них со значенями по умолчанию (в конце списка параметров) и мне хочется только один передать:
Уж получше чем указывать значения, равные тем, что по-умолчанию, для всех предыдущих параметров:В чем именно «соль» использования параметров без имени после именованых — не понятно. В вашем примере первый вариант самый правильный. Посмотреть сигнатуру метода (если нужно) можно простым мышконаведением в нормальной IDE, а каждый раз писать второй вариант — перебор.
Например, именование параметров при вызове возможно необходимо, чтобы при рефакторинге получить ошибки по всех вызовах где позиция не совпадет? А зачем?
Про подчеркивание не понял вообще, что за проблему решили.
Вы, скорее всего, решаете какую-то определенную задачу, и потому вам, возможно, потребуется другой обьект, не Interval. Но я так и не смог понять, для решения какой задачи нужно зачему-то разбивать интервал на континуумы и хранить их.
И не хватает выводов, что с того, что Interval такой, а не другой (который вам нужен)? Чем такое моделирование плохо?
Вообще я заметил, что нам (программистам) свойственно «додумывать» различные условия и крайности. Это хорошо видно на stackoverflow, когда плохо сформулированные вопросы неожиданно получают несколько ответов, решающих разные проблемы.
В вашем случае, выбрав Б, вы «додумываете» некую «сохранностить данных». В моем случае, выбирая А (см. мой комментарий ниже), я «додумываю» некую синхронность отрисовки, типа кольцо сначала должно быть убрано, а уже потом добавлено.
«Сильный» программист просто знает правильный порядок, допустим, если бы были задержки при синхронной отрисовке или анимации, то правильный порядок был бы «убрать кольцо с 1» (требует 2 команды, из-за того, что прямоугольники накладываются друг на друга оптимальный порядок единственный) и «добавить кольцо к 2», т.к. тогда кольцо сначало было бы убрано, а потом надето, как в реальности. Несмотря на то, что вы добавили условие «нет анимаций» именно этот путь наиболее «логичный».
Последняя программа тоже логична, она просто сперва очищает экран, а потом рисует то состояние, которое нужно. Это может быть более оптимальный путь, если ввести несколько уровней абстракции, к примеру, добавить очередь/список команд, при изменение которого потребуется перерисовка, перед которой экран всегда будет очищаеться. Повысится читаемость, модифицируемость и поддерживаемость программы за счет производительности. Что лучше — зависит…
Вообще понять мысли разглядывая код написанный другим, если только он не намного ниже вашего уровня мышления/программирование, это сложная задача. Комментарии и использование стандарных паттернов/именований облегчает задачу.
Мне кажется, в статье хорошо освещена проблема (мне сложно представить мысли человека, выбравшего В или С). А вот анализа и решения (что с этим делать) — увы нет.
Мне интересно кто берет в штат людей, меняющих фирмы как носки? И на что они расчитывают? Я б не взял. Смысл? Уйдет ведь, с высокой вероятностью…
Скорее всего проблема в авторе, а не в окружающем мире. Книжки читать полезно, но возможно нужна помощь специалиста? Неужели комментарии с минусами ни о чем не говорят?
История о неудачах другим была бы полезной. А учить как надо — пожалуй не стоит…
Конкурс в кавычках, потому что это никакой не конкурс, я правильно понимаю? Или есть жюри и призы? Автору просто захотелось запостить свой код, возможно весьма крутой (не владею питоном), но это не делает его хоть чуточку полезнее.
Предыдущая статья тоже «ни о чем», впрочем там хоть какой-то смысл был, а здесь? 15 скриншотов это статья?
Жду с нетерпением следущую статью, боюсь даже предположить, о чем (и да /sarcasm).
Или вы не в теме (не веб разработчик) и по лайкам там решили, что тема достойная для хабра?
Прямо хочется, чтобы для любого перевода был обязательный абзац «Почему я это перевел». Уже ее первый раз вижу, когда треш (а это именно треш, мусор, популистская статья, бессмысленная и бесполезная) переводят и публикуют тут. Не понимаю в расчете на что? С одной стороны усилия потрачены (на перевод), перевод вроде не плохой (читается легко), а с другой — блин, ну зачем? На какую аудиторию рассчитана статья?
Судя по всему, вы путаете назначение полей и свойств. Свойства как раз для того и нужны, чтобы добавить некую «простую» логику, чего нельзя сделать для поля. Интуитивно я понимаю, что вы имели в виду. Если эта логика переиспользуется или слишком сложна (много строк или различающихся по смыслу действий?) для свойства, то ее имеет смысл вынести в отдельный (переиспользуемый) метод или даже в несколько.
В вашем примере, если Name — это свойство, при установке которого должны установится другие, то вполне ожидаемо получить исключение при ошибке парсинга или конвертации. Например, FullName может ожидать пробел и/или более одного слова, чтобы установить FirstName и LastName.
Не критикую ни капли, просто задумался, например, напиши вы такое в комментах — я бы и не заметил, а в статье почему-то «задевает». То ли «призма авторитета», то ли ощущение «успешного человеа» (зависть?), не пойму в чем дело.
В статье вообще, от слова полностью, не раскрывается тема. Так, на поржать. А тема вообще-то серьезная. Может стоило бы хотя бы сменить название на шутливое? А то вон веб-разработчики (хирурги интернета) со своей спецификой работы приняли это слишком близко к сердцу выше ;)
С одной стороны, разница между профессионалом и любителем очевидна. С другой — поделить людей на 2 группы, белых и черных, не выйдет. Вы предлагаете нанимать любителей, это как вообще делается? «Фирма ищет любителей, профессионалам не беспокоится»? Аналогично с профессионалами, при найме на работе, какой критерий использовать, после которого человек вдруг из любителя становится профессионалом? Спрашивать: «Вы уходите домой ровно в 17:00»?
А когда до NLP добрался, выдохся что-ли? Или будет следующая статья?