Решил я тут намедни Дотнет с Додиезом и прочими ВПЭФами освоить.
Пенсионер жеж — для собственного удовольствия...

Задачку себе выбрал: система психологического тестирования.
Потом студентам буду показывать процесс эволюционного развития системы и на паттерны показывать.
Чтобы одновременно не заморачиваться всем сразу, отложил работу с базой на попозже, и проектирование оконного интерфейса — тоже.
Тут просится паттерн прокси на место DB.

Основная часть сейчас — написать собственно тестилку.
Практически все тесты обрабатываются однотипно.
Поэтому первое, что автоматом сделал — паттерн Шаблонный метод.
Хотя Боб Мартин еще советует посмотреть в сторону Стратегии. Посмотрим. Пока неясны выгоды того и другого.
Шаблонный метод — очень понятный паттерн и в данном случае применяется просто в лоб.

У каждого теста есть набор вопросов.
И тестов этих много — ну, штук 200-300. Тут просится Фабрика — это понятно.

При писанине возникли некоторые вопросы к знатокам.
1. Список тестов.
Его легко сделать в виде обычного текстового файла.
Это чтобы можно было туда добавлять новые.
За каждой строкой "стоит" тест (объект в программе) и он имеет список своих вопросов.
Можно этот список вопросов запихать в файл и связать его имя со строкой в списке тестов.

Например:
1. Тест Кеттела = Q0001
2. Тест Айзенка = Q0002
Вот этот список тестов — в ресурсы запихать, или оставить как чисто простой текстовый файл?
Есть ли смысл в использовании ресурсов в данном случае?
Это ж тоже изучать в данном случае — Студия дофига кода генерит для ресурсов.

2. А когда тест выбран для работы, метод Initialization() просто читает в List<string> из соответствующего файла.
Или просто в лоб в коде присвоить имя файла?
В связи с этим: пока не совсем понятно, когда использовать свойства.
Вот например, для имени файла с вопросами использовать поле или свойство?

3. Нет опыта использования интерфейсов.
Когда использовать классы, когда интерфейсы (ну, кроме понятных случаев множественного наследования).
Боб Мартин паттерн Стратегия описывает как второй вариант решения одной и той же задачи.
И как раз описывает стратегию с помощью интерфейса.
А потом разные стратегии у него реализуются разными классами.

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

LVV>Поэтому первое, что автоматом сделал — паттерн Шаблонный метод.
Стоять ать-два. Вот так делать никогда и ни при каких обстоятельствах не надо, это прямой путь к запороть весь проект.


Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.

Недавно обсуждалось вот тут

Автор: okon
Дата: 20.02.16

, цитата для затравки:

вы же не думаете в стиле "у меня есть шуруповёрт, значит, мне нужно собрать шкаф, потому что часы им разбирать неудобно"?
Ну так почему для разработки такой способ мышления считается нормальным?

LVV>Хотя Боб Мартин еще советует посмотреть в сторону Стратегии. Посмотрим. Пока неясны выгоды того и другого.
У Боба Мартина всё классно, кроме одного — он не решает проблемы, он творчески натягивает паттерны. В результате получается симпатично

	и как-то так

В общем, если вам для дела, а не для заготовок сфероконины в промышленных масштабах, то ни Фаулер, ни тем более Мартин — не авторитет.


LVV>Шаблонный метод — очень понятный паттерн и в данном случае применяется просто в лоб.
LVV>У каждого теста есть набор вопросов.
Посмотрите ссылку на обсуждение выше, я там расписывал с примерами, как надо рассуждать при формулировке начального ТЗ.

Будут реальные сценарии — можно будет и конкретные решения обсудить. А то с тем же успехом можно дротики в оглавление Фаулера метать и писать выпавшее. Шансы угадать те же.

LVV>>Поэтому первое, что автоматом сделал — паттерн Шаблонный метод.
S>Стоять ать-два. Вот так делать никогда и ни при каких обстоятельствах не надо, это прямой путь к запороть весь проект.
Почему?
Все тесты обрабатываются совершенно одинаково:
— есть несколько десятков вопросов.
— вопросы задаются пользователю.
Обычно чисто последовательно, но это не критично — можно и все сразу показать, а пользователь будет сам выбирать.
— принимается ответ.
После получения всех ответов — расчет показателей теста.
Далее эти результаты сохраняются в каком-то виде в БД.
И можно показать пользователю.
Пока все.
S>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.
Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод.
S>Недавно обсуждалось вот тут

Автор: okon
Дата: 20.02.16

, цитата для затравки:
S>

S>вы же не думаете в стиле "у меня есть шуруповёрт, значит, мне нужно собрать шкаф, потому что часы им разбирать неудобно"?
S> Ну так почему для разработки такой способ мышления считается нормальным?

Спасибо, почитаю.

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

LVV>Почему?

По жизни. Можно, конечно, забивать гвозди микроскопом. Но может оказаться, что молотком удобнее и эффективнее.

LVV>Все тесты обрабатываются совершенно одинаково:
LVV>- есть несколько десятков вопросов.
LVV>- вопросы задаются пользователю.
LVV>Обычно чисто последовательно, но это не критично — можно и все сразу показать, а пользователь будет сам выбирать.
LVV>- принимается ответ.
LVV>После получения всех ответов — расчет показателей теста.
LVV>Далее эти результаты сохраняются в каком-то виде в БД.
LVV>И можно показать пользователю.
LVV>Пока все.

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

S>>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.

+100500.

LVV>Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод.

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

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

LVV>Его легко сделать в виде обычного текстового файла.

Лучше его сделать в виде обычного XML или обычного JSON файла.

LVV>Это чтобы можно было туда добавлять новые.
LVV>За каждой строкой "стоит" тест (объект в программе) и он имеет список своих вопросов.
LVV>Можно этот список вопросов запихать в файл и связать его имя со строкой в списке тестов.

Неудобно когда информация о тесте раскидана по нескольким файлам.

LVV>Есть ли смысл в использовании ресурсов в данном случае?

Не особо.

LVV>Это ж тоже изучать в данном случае — Студия дофига кода генерит для ресурсов.

Изучать там нечего. И генерацию можно убрать.

LVV>2. А когда тест выбран для работы, метод Initialization() просто читает в List<string> из соответствующего файла.
LVV>Или просто в лоб в коде присвоить имя файла?

Вопрос непонятен.

LVV>Вот например, для имени файла с вопросами использовать поле или свойство?

Код покажи.

LVV>3. Нет опыта использования интерфейсов.
LVV>Когда использовать классы, когда интерфейсы (ну, кроме понятных случаев множественного наследования).

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

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

S>>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.
LVV>Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод.

Нет, это не задача.
Начни с тестов (nunit-тестов, а не своих). Как бы ты хотел, чтобы выглядел код, использующий эти самые тесты?
Например:

var testManager = TestManager.Create(new TestSourceMock(testXml));
var test = testManager.Get("Kettel");
Assert.AreEqual("Тест Кеттела", test.DisplayName);
Assert.AreEqual(3, test.Questions.Count);
Assert.AreEqual("Вопрос 1 ...", test.Questions[0].Text);
Assert.AreEqual(QuestionType.Exclusive, test.Questions[0].Type);
Assert.AreEqual(2, test.Questions[0].Answers.Count);
Assert.AreEqual("Ответ А", test.Questions[0].Answers[0]);
...

Ну и самое сложно в твоей задаче — понять какие типы тестов ты хочешь покрыть и как эти типы объединить одной моделью. Как вопросы организованы, как результат теста вычисляется, нужен ли rich text в вопросах и ответах и т.п. А все эти рассказы про шаблоны — ненужные подробности на данном этапе.

LVV>>Все тесты обрабатываются совершенно одинаково:
LVV>>- есть несколько десятков вопросов.
LVV>>- вопросы задаются пользователю.
LVV>>Обычно чисто последовательно, но это не критично — можно и все сразу показать, а пользователь будет сам выбирать.
LVV>>- принимается ответ.
LVV>>После получения всех ответов — расчет показателей теста.
LVV>>Далее эти результаты сохраняются в каком-то виде в БД.
LVV>>И можно показать пользователю.
LVV>>Пока все.
L>И куда в этом описании пихать шаблонный метод? Возможно, он пригодится где-то в процессе реализации каких-то частей этой последовательности, но на таком уровне никакой надобности в нем не наблюдается.
Дык это он и есть.
Абстрактный алгоритм работы теста.
Различия — в деталях: вопросы, ответы, способ обработки.
S>>>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.
L>+100500.
LVV>>Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод.
L>Шаблонный метод — это инструмент. Он не может быть решаемой задачей (кроме случая, когда стоит задача написать шаблонный метод. Но это ведь не тот случай, да?).
Шаблонный метод — подходящий в данном случае инструмент.
Пока вы меня не убедили, что он здесь не подходит.

S>>>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.
LVV>>Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод.
AVK>Нет, это не задача.
AVK>Начни с тестов (nunit-тестов, а не своих). Как бы ты хотел, чтобы выглядел код, использующий эти самые тесты?
AVK>Например:
AVK>

AVK>var testManager = TestManager.Create(new TestSourceMock(testXml));
AVK>var test = testManager.Get("Kettel");
AVK>Assert.AreEqual("Тест Кеттела", test.DisplayName);
AVK>Assert.AreEqual(3, test.Questions.Count);
AVK>Assert.AreEqual("Вопрос 1 ...", test.Questions[0].Text);
AVK>Assert.AreEqual(QuestionType.Exclusive, test.Questions[0].Type);
AVK>Assert.AreEqual(2, test.Questions[0].Answers.Count);
AVK>Assert.AreEqual("Ответ А", test.Questions[0].Answers[0]);
AVK>...
AVK>

AVK>Ну и самое сложно в твоей задаче — понять какие типы тестов ты хочешь покрыть и как эти типы объединить одной моделью. Как вопросы организованы, как результат теста вычисляется, нужен ли rich text в вопросах и ответах и т.п. А все эти рассказы про шаблоны — ненужные подробности на данном этапе.
1. Спасибо за пример юнит-тестов. А то я думал, как их писать.
2. Покрываются ВСЕ психологические тесты-опросники. Их много — до нескольких сотен.
Схема тестирования у всех одинакова — я приводил. Разница — в наборах вопросов, естественно, ответах и обработке ответов.
Не покрываются тесты другого вида (пока так представляется), например, тест Люшера.
3. Отсюда — вопросы у всех тестов организованы одинаково... Просто последовательность строк.
Пока отставил проектирование диалогового интерфейса — сначала хочу движок состряпать.

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

LVV>3. Отсюда — вопросы у всех тестов организованы одинаково... Просто последовательность строк.

Как минимум, для разных вопросов ответы могут быть только один вариант или возможность выбрать несколько.

LVV>Пока отставил проектирование диалогового интерфейса — сначала хочу движок состряпать.

Подумай еще над тем, где сами тесты хранить, куда сохранять результаты тестирования, как идентифицировать тестируемого и т.п.

LVV>>3. Отсюда — вопросы у всех тестов организованы одинаково... Просто последовательность строк.
AVK>Как минимум, для разных вопросов ответы могут быть только один вариант или возможность выбрать несколько.
Ну, это как раз те конкретные детали, которые просто уточняют общую схему.
LVV>>Пока отставил проектирование диалогового интерфейса — сначала хочу движок состряпать.
AVK>Подумай еще над тем, где сами тесты хранить, куда сохранять результаты тестирования, как идентифицировать тестируемого и т.п.Ну, это тоже само-собой.
Ибо тут придется проектировать схему БД.
Поэтому пока вместо БД — заглушка.

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

AVK>>Как минимум, для разных вопросов ответы могут быть только один вариант или возможность выбрать несколько.
LVV>Ну, это как раз те конкретные детали, которые просто уточняют общую схему.

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

AVK>>Подумай еще над тем, где сами тесты хранить, куда сохранять результаты тестирования, как идентифицировать тестируемого и т.п.Ну, это тоже само-собой.
LVV>Ибо тут придется проектировать схему БД.
LVV>Поэтому пока вместо БД — заглушка.

Да бог с ней, с БД. Ты хотя бы определись — это будет единое хранилище на сервере или локальное.

LVV>>Ибо тут придется проектировать схему БД.
LVV>>Поэтому пока вместо БД — заглушка.
AVK>Да бог с ней, с БД. Ты хотя бы определись — это будет единое хранилище на сервере или локальное.
На сервере.

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

LVV>На сервере.

Вот с этого тогда и надо начинать. Определись хотя бы с базовыми параметрами — в каком виде у тебя будет серверная часть,какой протокол. Или может быть там веб-интерфейс у тестов будет. Как регистрировать и аутентифицировать пользователей. Как на сервер добавлять данные. Как просматривать результаты тестирования.

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

LVV>3. Нет опыта использования интерфейсов.
LVV>Когда использовать классы, когда интерфейсы (ну, кроме понятных случаев множественного наследования).
LVV>Боб Мартин паттерн Стратегия описывает как второй вариант решения одной и той же задачи.
LVV>И как раз описывает стратегию с помощью интерфейса.
LVV>А потом разные стратегии у него реализуются разными классами.

Вообще тут роли напрашиваются. Админ который будет добавлять в систему преподов. Преподы, которые будет добавлять тесты и студентов, ну студенты конечно. А так это как-то "сферично" и "ваккуумно".

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

LVV>>На сервере.
Это я так планирую довести до этого.
AVK>Вот с этого тогда и надо начинать. Определись хотя бы с базовыми параметрами — в каком виде у тебя будет серверная часть,какой протокол. Или может быть там веб-интерфейс у тестов будет. Как регистрировать и аутентифицировать пользователей. Как на сервер добавлять данные. Как просматривать результаты тестирования.
1. Систему планирую потом использовать только на кафедре.
Пока мыслю — в пределах одного компьютерного класса с базой на локальном кафедральном сервере.
Это примерно 14-15 компов одновременно.
2. Все добавления-модификации информации буду делать сам или знакомый препод.
Прямо на кафедральном компе. Поэтому новых преподов не нужно регистрировать.
3. Студенты будут региться из класса.

В этом деле опыта нет абсолютно.
Наверное, тонкий клиент?
Ибо от пользователя требуется только вводить ответы.
Пока все ответы не получены — ничего считать не надо.

Неужто интерфейс просто ручками в html сваять?

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

LVV>1. 2. 3.
Воот.. уже прорисовываются сценарии использования с характеристиками окружения. С этого и надо начинать. Дальше немного детализировать до появления схем взаимодействия и можно код начинать писать.

LVV>Наверное, тонкий клиент?
LVV>Ибо от пользователя требуется только вводить ответы.
LVV>Пока все ответы не получены — ничего считать не надо.

LVV>Неужто интерфейс просто ручками в html сваять?
Вполне возможный вариант
Я бы делал примерно так:
HTML + CSS + JS на клиенте, т.к. функционал простой и сразу решается вопрос обновления версий
REST сервис на сервере (WebAPI, C# .NET 4.5 + там много чего готового есть для авторизации и прочих типовых задач)
Либо, если веб интерфейс не нужен и хочется 100% .NET на клиенте и сервере
WPF приложение на клиенте — тут как раз можно применить всякие MVVM и прочие паттерны
WCF сервис на сервере
Можно вообще не делать сервис а напрямую цепляться к БД из клиентов, но.. советовать такое пожалуй не буду.

A>Я бы делал примерно так:
A>HTML + CSS + JS на клиенте, т.к. функционал простой и сразу решается вопрос обновления версий
A>REST сервис на сервере (WebAPI, C# .NET 4.5 + там много чего готового есть для авторизации и прочих типовых задач)
Где читать?
A>Либо, если веб интерфейс не нужен и хочется 100% .NET на клиенте и сервере
A>WPF приложение на клиенте — тут как раз можно применить всякие MVVM и прочие паттерны
A>WCF сервис на сервере
Опять же — где читать про взаимодействие клиента и сервера?

LVV>Где читать?
Для поверхностного ознакомления и быстрого старта например тут >> http://metanit.com/sharp/aspnet_webapi/

LVV>Опять же — где читать про взаимодействие клиента и сервера?
Ну... например нагуглить какую-нибудь статью по запросу WCF Tutorial для ознакомления, потом какую-нибудь книжку посолиднее . По технологиям там ничего экстраординарного, а вот правильно спроектировать интерфейс сервиса — этому придется подольше учиться.

Ок.
Как отлаживать на одной машине?
Сервер на виртуалке поднять?