Несколько объектов, записывающих данные: как этого избежать
Вы знаете те случаи, когда вы работаете над программой, и в вашем коде есть места, которые, в зависимости от требований или ошибки, которая каким-то образом проявляется, напрямую связаны с тем, что у вас есть несколько объектов, записывающих данные. в то же хранилище данных? Это не очень хорошо.
Это ужасный способ начать пост. Позвольте мне попробовать это снова.
Несколько объектов, записывающих данные
Скажем, вы работаете над программой, и одна из вещей, которую делает код, — это обновление счетчика где-то в базе данных, чтобы отслеживать, сколько изменений произошло за небольшой период времени.
Проблема: у вас есть несколько мест в коде, которые обновляют этот счетчик.
Несколько объектов записывают данные (на случай, если мой почерк настолько неразборчив, насколько кажется).
Я не думаю, что многие из нас собирались писать код, подобный этому, но это случается, и когда это происходит, это заканчивается всеми этими побочными эффектами, которые просто порождают все виды причудливого поведения. (Я не знаю официального, академического термина для этого — и я не имею в виду DRY — но я согласен с «причудливым поведением» для этого поста.)
Мы интуитивно понимаем, что у нас должно быть единое место, где все это происходит, внешние факторы — будь то расширение масштаба, непонимание с нашей стороны при понимании требований или что-то еще — порождают плохое кодирование.
Таким образом, у нас есть все эти объекты в нашей системе, каждый из которых общается с одной точкой в нашей базе данных (или в любом другом хранилище данных), но ни один из них не знает, что другие говорят с ними.
Установите границы
Мы можем попытаться бороться с этим с помощью условных выражений или чего-то еще, но мы только усугубим ситуацию. Итак, что мы должны делать?
Я знаю, что, как и со многими другими вещами в программировании, есть множество способов решить эту проблему, но, возможно, одним из первых этапов рефакторинга является создание класса, отвечающего за выпуск обновлений в хранилище данных.
Таким образом, мы можем перейти от иллюстрации выше к чему-то вроде этого:
Несколько объектов, записывающих данные: отправьте их своего рода посреднику.
То есть все сущности общны с этим объектом и этим объектом — и только этот объект может читать и записывать данные в базу данных.
Есть несколько шаблонов проектирования, которые подходят для этой конкретной проблемы, но это выходит за рамки этого поста. Вместо этого я пытаюсь подчеркнуть, что если вы столкнулись с проблемой:
- Сущности записывают данные в хранилище данных,
- Это делают несколько субъектов,
- И это порождает непредвиденные последствия,
Затем попробуйте создать класс или набор классов, строго отвечающих за чтение и запись данных. Позвольте информации проходить только через эти классы, вместо того, чтобы несколько классов выполняли манипуляции с данными.
Это упрощает тестирование, упрощает отладку и, в конечном счете, облегчает чтение.