Вот как только класс будет отнаследован — тогда и будете тестировать наследника.
Вы меня не поняли, я вообще не собирался тестировать наследника. Я тестировал работу исходного класса, к тому же его Public-метода
А пока — вы предложили создать хрупкие тесты, завязанные на реализацию. Которые сломаются от малейшего рефакторинга.
В конце статьи я, кстати, указал на этот недостаток. В ряде задач, реализующих последовательность некоторых шагов как, например, Шаблонный метод правильность алгоритма можно протестировать именно через тестовый класс-наследник, как показано в примере. Если вы предложите лучший вариант тестирования, без завязки на реализацию, то с удовольствием выслушаю вас…
Подходы могут быть различные, ничего в этом плохого нет — все зависит от конкретной задачи. Что б лучше понять — немного процитирую (кстати мой вариант второй).
"… для тестирования классов применяются тестовые драйверы. Существует несколько способов реализации тестового драйвера:
Тестовый драйвер реализуется в виде отдельного класса. Методы этого класса создают объекты тестируемого класса и вызывают их методы, в том числе статические методы класса. Таким способом можно тестировать public часть класса.
Тестовый драйвер реализуется в виде класса, наследуемого от тестируемого. В отличие от предыдущего способа, такому тестовому драйверу доступна не только public, но и protected часть.
Тестовый драйвер реализуется непосредственно внутри тестируемого класса (в класс добавляются диагностические методы). Такой тестовый драйвер имеет доступ ко всей реализации класса, включая private члены. В этом случае в методы класса включаются вызовы отладочных функций и агенты, отслеживающие некоторые события при тестировании."
Я не призываю вас тестировать закрытые члены класса. Но если классу предоставляется возможность наследования, как в приведенном варианте, то тестирование его protected части вполне себе оправдано. А насчет внесения изменений и понять как все работает — в этом как-раз написанные тесты вам и помогут.
Это технология скинения WinForms приложений, используя DevExpress XtraSkins. Там есть галерея, так что если есть желание — можете ознакомиться. ) Вот тут даже более показательный вариант для чекбокса. А вообще практически все UI-элементы могут быть нарисованы, используя различные (офисные, тематические и др.) скины. Вот, например, вариант скинов для Хеллоуина.
XtraScheduler, как и Outlook Calendar имеет форму редактирования, из которой должна открываться еще одна модальная в случае рекуррентности. Именно с этим связанны основные сложности при передачи объектов/копий между формами с последующим откатом или изменением, когда меняется ТИП объекта. Корректно применить текущее состояние к исходному объекту пользователю будет довольно проблематично, т.к. при этом задействованы даже internal методы. В контроллере эта реализация скрыта и оттестирована.
Трабла в том, что теперь придется извращаться, когда модель поведения формы пользователем вами для него не предусмотрена. Как скрыть кнопку, как показать галку, как сделать так чтобы когда у меня это, то там появляется то
Я же не утверждаю, что взял наш класс и получил 100% результат =). Либое кастомное решение может вностить свои требования. Хотите расширяйте контроллер для своих нужд (он же прямо в форме и создан) — расширяйте, если не нравится так — пишите лоигку прямо в форме, а потом дублируйте ;) В любом случае — это вам решать.
Не получается серебряной пули, и рутина уйдет тогда когда пользователи компонент по своей бизнес модели совпадают с той моделью, которой вы придерживались при написании оных компонент.
Не пойму, и наша форма и пользовательская редактируют один и тот же бизнес-объект, что может концептуально не совпадать? Если есть custom-свойства, пожалуйста заводите в наследнике то, что не хватает и используйте. В контроллере для этого предусмотрены виртуальные методы типа ApplyCustomFieldsValues, ApplyRecurrence, RemoveRecurrence и т.д.
Возможно, я немного смотрю на вопрос с точки зрения компонентной разработки, а не законченного конечного приложения, если форма статичная…
Что вы скажете о «рутине» для большого количества пользователей, если каждому из которых придется реализовывать ВЕСЬ функционал формы?
Мы дали им решение, которое облегчило и ускорило им разработку. Разве это плохо? Несколько лет успешной жизни проекта тому доказательство.
Насчет платформ и рутины — у нас наследники AppointmentFormController-а содержат только перегруженный конструктор и 1-2 свойства типа Control, Storage, опять же для того, что б избежать ненужного кастинга в формах пользователей. При нежелании можно было бы обойтись и одним классом на все платформы. Не верите, посмотрите, тем более у вас есть подписка.
Отвечу, исходя из реального сценария применения контроллера. Пользователь создает кастомную форму со своим лайаутом, редакторами и прочими элементами. Мы предоставляем «черный ящик» с интерфейсом, он просто биндит/устанавливает свойства и зовет ApplyChanges(). В противном случае, без контроллера формы он вынужден будет знать о структуре редактируемого объекта и правильным образом и в правильно порядке осуществлять его модификацию и сохранение. При создании аналогичной формы с другим UI или на другой платформе логику придется реализовывать повторно, что связано с определенным риском. «Черный ящик» и повторное использование — вот основная разница в подходе.
Я, как автор статьи, посчитал уместным ответить на ваш комментарий. Мне не понятно, почему это вас так задело — разве выразить свое мнение комментарий человека, прочитавший мою статью считается плохим тоном?
Для вас никто не отменял. Для меня — никто не показывал.
Согласитесь, что покажи я форму с одной кнопкой — это не соответсвовало бы теме статьи. Думаю, тут все логично. Ну а вы, как человек, знакомый с iCal вроде бы должны хорошо представлять динамику подобного рода форм.
… она мне не очень нравится. По нескольким причинам. Одна из них — изменение стандартного вида системных компонент.
Вам же знакомы такие понятия как аппиранс, скинов, темы, стили. Показываемый скриншот — лишь один из нескольких таких вариантов. Можете посмотреть на нашем сайте.
>Если хотелось сделать красиво — надо использовать более кастомные элементы и дизайн получше сделать.
Не спорю, форма далека от совершенства. Лично мне
Мы пишем компоненты, так что особую красоту наводят уже наши пользователи.
В статье привежен распахнутый вариант нашей формы, но никто не отменял и ее сжатый вид:
Вы немного притягиваете свой пример за уши =) Включите Alarm (напоминатель) и выставите Repeat (Рекуррентность) в значение отличное от None. И давайте сравним ваши 2 примера.
От Вас жду еще один скриншот полной формы…
Насчет перегруженности — если в форме соблюдена визуальная иерархия, правильный визуальный поток и группировка (4 гештальт-принципа), то даже форма с большим количеством элементов может иметь правильный дизайн. И тому есть масса примеров.
Видите чекбокс Recurrence? Если его сбросить — весь контент связанный с рекуррентностью скроется. Это может быть чекбокс, комбик, кнопка с модальной формой — суть от этого не меняется. В один момент времени вы видите детали только для ОДНОГО вида рекуррентности.
Касательно планировщиков вообще, пока кардинально-нового интерфейса никто не придумал. Не нравится Outlook-style, посмотрите аналоги в том же Google или Яндекс-Календаре — смысл у всех тот же, не в визарде же параметры настраивать =)
Да, в WPF-ой версии для нормального механизма Binding мы использовали Dependency объекты и свойства, но внутри — все тот же форм-контроллер, реализующий логику работы с исходным объектом.
Вынести отделить отображение объект в форме — это позволит в дальнейшем проще модифицировать дизайн формы, вдобавок даст возможность использовать это в разных формах
Если вы про набор «готовых» редакторов/контролов для отображения различных видов рекуррентности и не только — то мы их поставляем вместе с планировщиком. Список посмотреть можете тут.
Потому что под рекурентные попадают 4 типа событий из пяти: сам объект-паттерн, 2 исключения (удаленный/измененный) со своими измененными правилами, и оккуренсы из цепочки, имеющие только индекс и ссылку на паттерн. Ваш вариант будет не верен для последних.
Реализация такая: IsRecurring { get { return Type != AppointmentType.Normal; } }
IsRecurring — нужно вынести в Recurrence (например Recurrence.Enabled)
Тут с вами не соглашусь, IsRecurring — это фасадное расчетное свойство, что бы не лазить всегда к внутреннему объекту.
Аналогично IsBase, IsOccurrence, IsExceptions. Код становится чище при большом числе обращений к такого рода свойств.
RecurrenceIndex и RecurrencePattern тоже могут быть прекрасно вынесены в Recurrence
Эти свойства события, а не рекурентного правила — не мешайте мух и котлеты )
Если создана рекурентная цепочка, то генерится N-объектов Appointment, для которых есть общие правила, т.е. общий шаблон, на который указывает свойство RecurrencePattern. А различаются только индексы в цепочке (за это в ответе свойство RecurrenceIndex). При этом свойство шаблона RecurrenceInfo нульное, т.к. сам объект не задает правило, а лишь создан по нему.
Нет конечно, я говорю об идее, как ее можно донести без утомительного описания в тексте. Короткое видео (буквально несколько секунд), показывающее цель или проблему порой гораздо информативнее для донесения идеи.
Вы меня не поняли, я вообще не собирался тестировать наследника. Я тестировал работу исходного класса, к тому же его Public-метода
В конце статьи я, кстати, указал на этот недостаток. В ряде задач, реализующих последовательность некоторых шагов как, например, Шаблонный метод правильность алгоритма можно протестировать именно через тестовый класс-наследник, как показано в примере. Если вы предложите лучший вариант тестирования, без завязки на реализацию, то с удовольствием выслушаю вас…
Подходы могут быть различные, ничего в этом плохого нет — все зависит от конкретной задачи. Что б лучше понять — немного процитирую (кстати мой вариант второй).
"… для тестирования классов применяются тестовые драйверы. Существует несколько способов реализации тестового драйвера:
Тестовый драйвер реализуется в виде отдельного класса. Методы этого класса создают объекты тестируемого класса и вызывают их методы, в том числе статические методы класса. Таким способом можно тестировать public часть класса.
Тестовый драйвер реализуется в виде класса, наследуемого от тестируемого. В отличие от предыдущего способа, такому тестовому драйверу доступна не только public, но и protected часть.
Тестовый драйвер реализуется непосредственно внутри тестируемого класса (в класс добавляются диагностические методы). Такой тестовый драйвер имеет доступ ко всей реализации класса, включая private члены. В этом случае в методы класса включаются вызовы отладочных функций и агенты, отслеживающие некоторые события при тестировании."
Я же не утверждаю, что взял наш класс и получил 100% результат =). Либое кастомное решение может вностить свои требования. Хотите расширяйте контроллер для своих нужд (он же прямо в форме и создан) — расширяйте, если не нравится так — пишите лоигку прямо в форме, а потом дублируйте ;) В любом случае — это вам решать.
Не пойму, и наша форма и пользовательская редактируют один и тот же бизнес-объект, что может концептуально не совпадать? Если есть custom-свойства, пожалуйста заводите в наследнике то, что не хватает и используйте. В контроллере для этого предусмотрены виртуальные методы типа ApplyCustomFieldsValues, ApplyRecurrence, RemoveRecurrence и т.д.
Что вы скажете о «рутине» для большого количества пользователей, если каждому из которых придется реализовывать ВЕСЬ функционал формы?
Мы дали им решение, которое облегчило и ускорило им разработку. Разве это плохо? Несколько лет успешной жизни проекта тому доказательство.
Насчет платформ и рутины — у нас наследники AppointmentFormController-а содержат только перегруженный конструктор и 1-2 свойства типа Control, Storage, опять же для того, что б избежать ненужного кастинга в формах пользователей. При нежелании можно было бы обойтись и одним классом на все платформы. Не верите, посмотрите, тем более у вас есть подписка.
Ну, это лишь вопрос терминологии Microsoft/Apple. Тут все зависит от предметной области.
Опять вы об интерфейсах. Статья, вообще-то, немного не об этом.
Тут с вами соглашусь.
А вы не помните более раннюю версию гугла? Там не было модальной формы
Как вам такое?
Согласитесь, что покажи я форму с одной кнопкой — это не соответсвовало бы теме статьи. Думаю, тут все логично. Ну а вы, как человек, знакомый с iCal вроде бы должны хорошо представлять динамику подобного рода форм.
Вам же знакомы такие понятия как аппиранс, скинов, темы, стили. Показываемый скриншот — лишь один из нескольких таких вариантов. Можете посмотреть на нашем сайте.
>Если хотелось сделать красиво — надо использовать более кастомные элементы и дизайн получше сделать.
Не спорю, форма далека от совершенства. Лично мне
Мы пишем компоненты, так что особую красоту наводят уже наши пользователи.
Вы немного притягиваете свой пример за уши =) Включите Alarm (напоминатель) и выставите Repeat (Рекуррентность) в значение отличное от None. И давайте сравним ваши 2 примера.
От Вас жду еще один скриншот полной формы…
Насчет перегруженности — если в форме соблюдена визуальная иерархия, правильный визуальный поток и группировка (4 гештальт-принципа), то даже форма с большим количеством элементов может иметь правильный дизайн. И тому есть масса примеров.
Касательно планировщиков вообще, пока кардинально-нового интерфейса никто не придумал. Не нравится Outlook-style, посмотрите аналоги в том же Google или Яндекс-Календаре — смысл у всех тот же, не в визарде же параметры настраивать =)
Кстати вы могли наблюдать наш стенд на РИТ2008.
Если вы про набор «готовых» редакторов/контролов для отображения различных видов рекуррентности и не только — то мы их поставляем вместе с планировщиком. Список посмотреть можете тут.
Реализация такая: IsRecurring { get { return Type != AppointmentType.Normal; } }
Тут с вами не соглашусь, IsRecurring — это фасадное расчетное свойство, что бы не лазить всегда к внутреннему объекту.
Аналогично IsBase, IsOccurrence, IsExceptions. Код становится чище при большом числе обращений к такого рода свойств.
Эти свойства события, а не рекурентного правила — не мешайте мух и котлеты )
Если создана рекурентная цепочка, то генерится N-объектов Appointment, для которых есть общие правила, т.е. общий шаблон, на который указывает свойство RecurrencePattern. А различаются только индексы в цепочке (за это в ответе свойство RecurrenceIndex). При этом свойство шаблона RecurrenceInfo нульное, т.к. сам объект не задает правило, а лишь создан по нему.