Запис даних кількома об’єктами: як цього уникнути
Ви знаєте ті випадки, коли ви працюєте над програмою, і є деякі місця у вашому коді, які, залежно від вимог або помилки, яка проявляється певним чином, безпосередньо пов’язані з тим, що у вас є кілька об’єктів, які записують дані до того самого сховища даних? Це погано.
Це жахливий спосіб почати публікацію. Дозвольте мені спробувати ще раз.
Запис даних кількома об’єктами
Скажімо, ви працюєте над програмою, і одна з речей, які робить код, це оновлення лічильника десь у базі даних, щоб відстежувати, скільки змін відбулося за невеликий проміжок часу.
Проблема: у вас є кілька місць у коді, які оновлюють цей лічильник.
Кілька об’єктів, що записують дані (якщо мій почерк такий же нерозбірливий, як здається).
Я не думаю, що багато хто з нас збирається писати такий код, але це трапляється, і коли це відбувається, це закінчується тими побічними ефектами, які просто породжують усі види дивної поведінки. (Я не знаю офіційного, академічного терміну для цього – і я не маю на увазі СУХИЙ – але я згоден із «фанковою поведінкою» для цієї публікації.)
Ми інтуїтивно знаємо, що у нас має бути єдине місце, де все це відбувається, зовнішні фактори – будь то розповзання обсягу, нерозуміння з нашого боку розуміння вимог чи щось інше – породжують погане кодування.
Таким чином, ми маємо всі ці сутності в нашій системі, кожна з яких спілкується з однією точкою в нашій базі даних (або в будь-якому іншому сховищі даних), але жодна з них не знає, що з ними спілкуються інші.
Встановіть межі
Ми можемо спробувати боротися з цим за допомогою умовних способів і чого ні, але ми лише погіршуємо ситуацію. Отже, що ми маємо робити?
Я знаю, що, як і з багатьма речами в програмуванні, існує безліч способів вирішити цю проблему, але, можливо, одним із перших етапів рефакторингу є створення класу, відповідального за видачу оновлень до сховища даних.
Таким чином ми можемо перейти від ілюстрації вище до чогось такого:
Кілька об’єктів записують дані: надішліть їх певному посереднику.
Тобто всі сутності спільно з цим об’єктом і цим об’єктом – і тільки цей об’єкт може читати та записувати дані в базу даних.
Є кілька шаблонів проектування, які підходять для цієї конкретної проблеми, але це виходить за межі цієї публікації. Натомість я намагаюся сказати, що якщо ви зіткнулися з проблемою:
- Суб’єкти записують дані в сховище даних,
- Кілька організацій роблять це,
- І це породжує непередбачені наслідки,
Потім спробуйте створити клас або набір класів, які суворо відповідають за читання та запис даних. Дозволяйте інформації проходити лише через ці класи, а не мати кілька класів для маніпулювання даними.
Це полегшує тестування, полегшує налагодження та, зрештою, полегшує читання.