РЕФАКТОРНЫЙ КОД СООБЩЕНИЯ
Создание настраиваемого кода за три простых шага
Жестко запрограммированный, неконфигурируемый код вызывает головную боль
Честно говоря, не так уж сложно писать отличные настраиваемые классы. Но может быть, если вы привыкли делать что-то определенным образом.
По моему опыту, лучший способ превратить существующий класс в настраиваемый - сначала переместить логику в отдельные классы, а затем переместить жестко запрограммированную часть в аргументы конструктора или метода.
Это так просто. Позвольте мне показать вам, как это сделать.
Но сначала, что такого хорошего в настраиваемом классе?
Прежде чем вы потратите время на рефакторинг существующих классов в настраиваемые, я дам вам знать, почему это так здорово.
Настраиваемый класс чертовски прост в использовании. Это расширяемое. Это не слишком много. Это просто глупо, и это здорово.
Самый большой плюс - это легко протестировать.
Познакомьтесь с классами
Для удобства вот краткий обзор классов, с которыми вы имеете дело.
У вас есть OrderProcessor класс с единственным методом ProcessOrder(Order).
Далее идет базовый класс Order и три подкласса VirtualOrder, ServiceOrder, ShippingOrder.
Понимание классов Order совершенно неуместно. Не отвлекайтесь на размышления о том, как они реализованы. Если вам действительно нужно знать, у них всего два свойства: «Имя» и «Цена» ... Хорошо, давайте продолжим.
Вы реализовали обработчик заказов следующим образом.
Реализация заняла 1 минуту. Оно работает. Ты счастлив. Ваш менеджер доволен. Ваш клиент доволен.
Но это беспорядок.
Это может быть переключатель. Но если это ваша первая мысль, вы сосредотачиваетесь на совершенно не относящихся к делу аспектах разработки программного обеспечения.
Позвольте мне показать вам, как это сделать лучше
Лучше конечно субъективно. Если вы уверены (вы не уверены), что этот класс никогда не изменится (изменится), это может быть отличная реализация (это не так).
Мы с вами реорганизуем этот беспорядок в разумный настраиваемый класс - без особых усилий.
Мы сделаем этот класс лучше по трем внутренним качествам программного обеспечения.
Читаемость. В настоящее время метод этого класса ужасно читается. У меня есть легкое решение для этого.
Ремонтопригодность. Если вам нужно изменить обработку «ServiceOrder», вы сделаете это в месте, окруженном несвязанным кодом. Кроме того, если другие разработчики работают над тем же классом, вы, вероятно, получите конфликты слияния. Раздражающие и потенциально вызывающие неожиданные ошибки.
Гибкость. Добавляете новый заказ? Вам нужно будет добавить еще else-if. Я уверен, что вы уже знаете, что это плохо и явное нарушение Open / Closed.
1 Повышение читаемости за счет преобразования IF в карты
Обычно для рефакторинга беспорядочного класса требуется несколько итераций. Во-первых, мы улучшаем читаемость. Трудно создать легко поддерживаемый и гибкий класс, если он нечитаем.
Полное избавление от if-else - отличный первый шаг.
Метод ProcessOrder(Order) стал намного проще для чтения, и теперь он выполняет только одну-единственную работу.
Если вы не знакомы с Action<T>, это просто лямбда, принимающая аргумент, или анонимная функция, если хотите.
Вместо этого мы взяли неприятный if-else и превратили его в словарь.
Также обратите внимание на дополнительное преимущество в отношении свойства OrderTypes. Если появляется новый тип заказа, нам не нужно вручную добавлять его в двух местах.
2 Создание отдельных классов улучшает ремонтопригодность
Мы могли бы легко остановиться на этом и положить конец этому. Вы уже сделали урок намного проще. Но вы еще не дошли до «глупого простого». Это наша конечная цель.
В настоящее время, с нашей первой итерацией рефакторинга, наш класс все еще слишком много знает о том, как обрабатывается каждый тип.
В этом случае обеспечение ремонтопригодности заключается в рефакторинге реализаций действий из класса процессора в их собственные классы.
В коде это выглядит следующим образом - обратите внимание на новый интерфейс IOrderProcessing. Каждое лямбда-действие из словаря теперь представляет собой отдельный класс.
Этот невероятно простой рефакторинг позволяет нам детально тестировать каждую обработку. Нам больше не нужно «обновлять» все OrderProcessor, чтобы просто посмотреть, например, виртуальный заказ обрабатывается правильно.
Ваш обработчик заказов начинает выглядеть действительно глупо. Просто так, как нам это нравится.
3 Последний рефакторинг для максимальной гибкости
Конечно, модульное тестирование на данном этапе очень просто. Но вам все равно придется трижды протестировать ProcessOrder(Order) метод, чтобы убедиться, что он работает правильно. Хуже того, это не очевидно. Чтобы понять это, вам нужно знать о внутреннем устройстве.
Для каждого нового типа заказа вам нужно будет протестировать тот же метод с дополнительным случаем. Это определенно запах кода.
Ваш последний рефакторинг сделает класс процессора удивительно простым. Вы просто превращаете экземпляр словаря в явную зависимость.
Такой легкий. Так просто. Так просто проверить.
Когда ваш код внезапно становится глупо простым, вы знаете, что достигли нужного уровня абстракции. Это как-раз тот случай. Поздравляю.
Рефакторинг для большего количества классов
Специалисты по информатике могут кричать от ужаса при добавлении каждого нового класса, вызывая потенциальные проблемы с производительностью (которые никогда не проявляются).
Что ж, есть компромисс во всем. Хорошо составленный код требует большего количества компонентов, чем запутанный, нечитаемый и молниеносный беспорядок. Выбрать свой яд.
Но, опять же, для хорошей меры, я провел простой тест производительности. 1 миллион итераций создания экземпляра нерефакторингового класса по сравнению с гибким классом, вызывая метод порядка обработки для каждого типа порядка.
Вы сами решаете, насколько ужасны эти цифры.
Resources for the curious ------------------------- Making Your C# Code More Object Oriented by Zoran Horvat Clean Code Principles in C# by Cory House Code Complete 2 by Steve McConnell
Никлас Миллард - инженер-разработчик программного обеспечения в одном из самых быстрорастущих банков, занимающихся созданием критически важной инфраструктуры финансовых услуг.
Ранее он был старшим техническим консультантом Big4 по разработке программного обеспечения для коммерческих клиентов и государственных учреждений.
Подключиться к LinkedIn
Лучшее программное обеспечение без« если-еще
5 способов заменить если-еще . Примеры от новичка до продвинутого medium.com »
