Войти
ПрограммированиеФорумОбщее

Тест на рефакторинг (C#) (14 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 19 10 11 12 13 14
#195
(Правка: 12:38) 12:35, 1 дек. 2018

tac
> соплежуй этот пример я анализировал 5 лет назад
не увидел твоего варианта кроме словоблудия (бла бла в комментариях анализом назвать никак нельзя)- код давай, или ты полностью согласен с гуру в его варианте ?

и да - в отличии от твоего задания/реализации в первом посте - код гуру хотя бы тестируемый :)

#196
(Правка: 17:18) 15:34, 1 дек. 2018

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

и да, я бы не стал делать возвращаемый массив отдельным свойством класса, как то сделал Мартин.

а в целом, книга 'совершенный код' достаточно бесполезная, в отличии от рефакторинга Фаулера .. она мне напомнила такую же бестолковую книгу Голуб Правила программирования .. и в той и в этой спутаны вопросы стиля программирования, действительно с важными вопросами чистого кода ..по стилю, есть одна полезна книга /названия не помню сходу .. да и кто тут читает, кому надо пишите .. посмотрю на полке тогда/

#197
12:01, 3 дек. 2018

tac
> я противник всяких тестов - это потеря времени
усё понятно - "не звоните нам больше - мы вам сами перезвоним" (с)

#198
13:11, 3 дек. 2018

tac
> с важными вопросами чистого кода

Чистый код – чистая нация!

Уже предлагали вариант "удалить написанный код", как рефакторинг?
#199
14:07, 3 дек. 2018

Решето Эратосфена расписанное на 8 методов. Лол. Для книги, возможно, этот пример имеет смысл (чтобы не загромождать текст описанием сложного алгоритма), но как тест - нет, нечего там рефакторить, это один короткий метод и никто не будет не то что расширять его функциональность а вообще открывать его пока он работает. Оптимизировать - да, можно, но тогда предварительное разбиение скорее навредит.

#200
14:29, 3 дек. 2018

Сделать IEnumerator<int> с yield вместо ада с аллокациями на каждый чих. Будет проще и понятней.

#201
14:59, 3 дек. 2018

Nerdman
> Сделать IEnumerator<int> с yield
> вместо ада с аллокациями на каждый чих
Взаимоисключающие параграфы)

#202
16:42, 31 дек. 2018

Продолжаем разговор, тут очередной специалист дал почву для размышлений :)

https://gamedev.ru/code/forum/?id=241124&page=5#m68

прошу заходим высказываемся )

#203
18:22, 31 дек. 2018

Надуманные искусственные пресные примеры, не несущие образовательной ценности.

Названия влияют, и лучше базовый класс назвать не Rooms, а RoomBase или что-то в таком духе. В остальном пример пустой и рефакторить там нечего.

#204
15:27, 1 янв. 2019

Есть предложение как сделать пример "не пустым". Представим что у нас не маленькая игра на три комнаты, а до сотни комнат, есть одинаковые, есть частично схожие (у которых совпадает часть доступных действий), десятки действий, некоторые доступны в зависимости от состояния игрока, некоторые задаются не словом а регекспом. В общем, сделать архитектуру которая будет масштабироваться хотя бы уровня предка таких игр, Collosal Cave Adventure. Разве что без предметов, раз уж их в изначальной задаче не было, но с учетом того что предметы тоже впоследствии будут добавлены.

#205
17:30, 1 янв. 2019

Я бы тогда сделал на компонентах вместо наследования. У комнаты есть список компонентов. Каждый компонент - одно действие. У него есть Help, он может быть активен или нет, и у него есть два метода - bool MatchCommand(string cmd) и PerformAction(). У комнаты тоже есть метод PerformAction(string cmd), в котором она проходит по списку активных компонентов и вызывает первый подошедший.

Хэлп-компонент, например, будет хранить у себя ссылку на комнату. В методе MatchCommand он будет сравнивать ввод с "?", "h" или "help", а в PerformAction будет вызывать у комнаты метод PrintHelp, в котором она будет печатать по очереди Help активных компонентов.

#206
0:39, 3 янв. 2019

Понятно, что тест там такой себе, элементарная вещь, но у умника не хватило ума признать свои ошибки .. поэтому, там скорее тест на адекватность

Что касается реального расширения примера, так понятно, что тогда появятся базы данных или как минимум граф /текстовый файл/ с описанием комнат, а код практически не изменится, останется базовый Rooms  .. но увы, тут не тот уровень чтобы это обсуждать

#207
2:43, 3 янв. 2019

tac
> Понятно, что тест там такой себе, элементарная вещь, но у умника не хватило ума
> признать свои ошибки
какие ошибки? xD

тебе даже тут говорят:
dayllenger
> Я бы тогда сделал на компонентах вместо наследования.

и даже так:

dayllenger
> Хэлп-компонент, например, будет хранить у себя ссылку на комнату. В методе
> MatchCommand он будет сравнивать ввод с "?", "h" или "help", а в PerformAction
> будет вызывать у комнаты метод PrintHelp, в котором она будет печатать по
> очереди Help активных компонентов.

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

#208
19:09, 3 янв. 2019

dayllenger
> Каждый компонент - одно действие. У него есть Help, он может быть активен или
> нет, и у него есть два метода
+1. Я бы, наверное, и простой пример так делал. Иначе help все время будет неактуальным - при изменениях действий его будут забывать менять.

tac
> тогда появятся базы данных или как минимум граф /текстовый файл/ с описанием
> комнат, а код практически не изменится, останется базовый Rooms .. но увы, тут
> не тот уровень чтобы это обсуждать
Почему не тот уровень? Что обсуждаешь, такой и уровень. Думаю, всем интереснее обсудить как граф задавать или в бд комнаты хранить, чем то, один за комнаты класс должен отвечать или два.

#209
2:19, 4 янв. 2019

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

Страницы: 19 10 11 12 13 14
ПрограммированиеФорумОбщее