Когда вы только начинаете изучать программирование — вы ещё не знакомы со многими техниками и концептами. Ваша первичная задача конечно же заставить программу работать, и справится с ней — не означает завершить свою работу. Это лишь первый этап, дальше вам нужно подготовить программу к последующим изменениям, и не просто наполнить её какими-то фишками которые «могут пригодится», а сделать всё так, чтобы её дальнейшая модификация не вызывала недопониманий и происходила без неявных побочных эффектов.

Этот подход открывает нам новый класс ошибок которые не так очевидны, особенно если у вас недостаточно опыта.

Одна из таких ошибок — попытка программировать данные.

В чём её суть?

Представьте что у вас в программе есть магазин, в магазине представлен список товаров.

Возьмём такой пример использования: у пользователя есть каталог товар, он может выбрать товар и при выборе у пользователя снимается со счёта стоимость товара.

Представим такой код:

 

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

Также, хоть у нас тут и мало кода, но у нас есть смешение логики и данных. Что это значит?

Формат вывода: в консоль, название товара, чёрточка и цена — это логика, хоть и отображения.

Она у нас дублируется, т.е на каждый товар мы дословно перепичатываем код.

Уже сейчас мы могли бы сделать например такой шаг:

 

Мы формализовали структуру товара через параметры функции. Это ещё неполноценный объект но мы уже идём в правильном направление.

В некоторых языках нам недоступно и это, особенно если мы работаем со старыми версиями которые не на том этапе эволюции.

Например мы вполне можем увидеть такой код в каком-нибудь языке:

 

И хоть это и выглядит глупо, такое мы можем представить и в C#. Например если вы работали с Unity, то там вы часто могли встретить поиск объектов, что очень напоминает код выше.

 

Тут мы сталкиваемся примерно с тем же: «Неочевидно что нужно для корректной работы функции».

Но давайте вернёмся к изначальному примеру.

Чем ещё плох хардкод? Это ещё и расходящаяся модификации. Это будет видно когда мы попробуем написать функцию снятия денег с баланса.

 

Мы в коде продублировали цены, имена и список товаров и это дублирование будет продолжаться с каждым новым функционалом. Почему мы сюда не передаём сразу цену?

Не удивляйтесь, такое бывает. Например программист передаёт в этот метод ввод от пользователя. Пользователь вводит название товара а функция уже принимает решение.

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

Например функция

private Item GetByName(string name)

Если вам кажется это всё слишком утрированным, то вот пример который каждый из нас может встретить. Код из реального проекта который прислали мне на обзор (полностью я его обозревать не буду и сейчас пытаюсь выделить одну из проблем и четко её осветить)

 

 

 

 

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

Например как связать чек-бокс и условный товар?

Мы можем сделать что-то подобное:

 

Роль ShapePickPanel в преобразование наших поверхностей в список чекбоксов для выбора и предоставление нам выбранных. Все поверхности программы у нас спрятаны в «репозитории» и если нам нужно что-то добавить мы это делаем в очевидной точке. А если нам нужно изменить вид чекбоксов или логику работы с ними мы тоже это будем делать в одной очевидной точке.

Подобные случаи мы прорабатываем на нашем профессиональном курсе «C# Medium» цель которого избавить вас от детских ошибок. Ревью там жесткое так, что готовьтесь к войне.

Подробности — http://ijunior.ru/csharp-medium?utm_source=vk&utm_medium=article&utm_campaign=ijunior&utm_term=ModificationExample