Проблема, яку створюють глобальні змінні для програміста, полягає в тому, що він розширює міжкомпонентну поверхню зв'язку між різними компонентами, які використовують глобальні змінні. Це означає, що зі збільшенням кількості компонентів, що використовують глобальну змінну, складність взаємодій також може зростати. Таке посилене з'єднання, як правило, полегшує введення дефектів у систему під час внесення змін, а також ускладнює діагностику та виправлення дефектів. Це збільшення зв'язку також може зменшити кількість доступних варіантів при внесенні змін, і це може збільшити зусилля, необхідні для змін, оскільки часто потрібно простежити різні модулі, які також використовують глобальну змінну, щоб визначити наслідки змін.
Метою інкапсуляції , яка в основному є протилежною використанню глобальних змінних, є зменшення зв'язку, щоб зробити розуміння та зміну джерела простішим, безпечнішим та легшим для перевірки. Набагато простіше використовувати тестування одиниць, коли глобальні змінні не використовуються.
Наприклад, якщо у вас є проста глобальна ціла змінна, яка використовується в якості перерахованого індикатора, який різні компоненти використовують як машину стану, а ви потім вносите зміни, додаючи новий стан для нового компонента, ви повинні простежити всі інші компоненти, щоб гарантувати, що зміни не торкнуться їх. Прикладом можливої проблеми може стати те, що в різних місцях використовується switchоператор для перевірки значення глобальної змінної перерахунку з caseоператорами для кожного з поточних значень, і так трапляється, що в деяких з switchоператорів немає defaultсправи для обробки несподіване значення для глобального раптом у вас не визначене поведінка, що стосується програми.
З іншого боку, використання спільної області даних може бути використано, щоб містити набір глобальних параметрів, на які посилається у всій програмі. Цей підхід часто використовується для вбудованих додатків з невеликими розмірами пам'яті.
При використанні глобальних змінних у подібних додатках, як правило, відповідальність за запис у область даних покладається на один компонент, а всі інші компоненти бачать область як constта прочитану з неї, ніколи не пишучи на неї. Такий підхід обмежує проблеми, які можуть розвиватися.
Кілька проблем із глобальних змінних, над якими потрібно вирішити
Коли джерело для такої глобальної змінної, як структура, модифікується, все, що використовується, повинно бути перекомпільовано, щоб все, що використовувало змінну, знало її справжній розмір і шаблон пам'яті.
Якщо більш ніж один компонент може змінити глобальну змінну, ви можете зіткнутися з проблемами з непослідовними даними, що знаходяться в глобальній змінній. За допомогою програми з багатопотоковою передачею вам, ймовірно, потрібно буде додати якусь блокувальну чи критичну область, щоб забезпечити спосіб, щоб лише один потік одночасно міг змінити глобальну змінну, і коли потік змінює змінну, усі зміни завершені і зроблено раніше, ніж інші потоки можуть запитувати змінну або змінювати її.
Налагодження багатопотокової програми, яка використовує глобальну змінну, може бути складніше. Ви можете зіткнутися з умовами перегонів, які можуть створити дефекти, які важко повторити. Коли декілька компонентів спілкуються через глобальну змінну, особливо в багатопотоковому додатку, бути в змозі зрозуміти, який компонент змінює змінну, коли і як вона змінює змінну, може бути дуже важко зрозуміти.
Зіткнення імен може бути проблемою при використанні глобальних змінних. Локальна змінна, яка має те саме ім'я, що і глобальна змінна, може приховати глобальну змінну. Ви також стикаєтеся з проблемою з умовами іменування під час використання мови програмування C. Робота полягає в тому, щоб розділити систему на підсистеми з глобальними змінними для певної підсистеми, починаючи з тих самих перших трьох літер (див. Це на вирішенні зіткнень простору імен у цілі C ). C ++ надає простори імен, і за допомогою C ви можете обійти це, створивши глобально видиму структуру, членами якої є різні елементи даних та покажчики на дані та функції, які надаються у файл як статичний, а також видимість файлу лише для того, щоб на них можна було посилатися лише через глобально видима структура.
У деяких випадках вихідний намір програми змінюється таким чином, що глобальні змінні, що забезпечували стан для одного потоку, змінюються, щоб дозволити запускати декілька повторюваних потоків. Прикладом може бути проста програма, призначена для одного користувача, що використовує глобальні змінні для стану, а потім від управління надходить запит на додавання інтерфейсу REST, щоб віддалені програми могли діяти як віртуальні користувачі. Отже, тепер у вас виникає необхідність дублювати глобальні змінні та інформацію про їх стан, щоб у одного користувача, а також у кожного віртуального користувача з віддалених додатків був свій унікальний набір глобальних змінних.
Використання C ++ namespaceта structметодики C
Для мови програмування C ++ ця namespaceдиректива є величезною допомогою для зменшення шансів зіткнення імені. namespaceпоряд із classрізними ключовими словами доступу ( private, protectedі public) надають більшість інструментів, необхідних для інкапсуляції змінних. Однак мова програмування на C не дає цієї директиви. Ця публікація stackoverflow, простори імен у C , пропонує деякі методи для C.
Корисна методика полягає в тому, щоб мати єдину область даних резидентної пам’яті, яка визначається як a, structяка має глобальну видимість, і всередині цього structє вказівниками на різні глобальні змінні та функції, які піддаються впливу. Фактичні визначення глобальних змінних задаються обсягом файлів за допомогою staticключового слова. Якщо ви використовуєте constключове слово, щоб вказати лише те, що читаються, компілятор може допомогти вам застосувати доступ лише для читання.
Використання structметодики також може інкапсулювати глобальний, щоб він став своєрідним пакетом або компонентом, який, як правило, є глобальним. Маючи такий компонент, стає легше керувати змінами, які впливають на глобальний та функціональний за допомогою глобального.
Однак в той час namespaceабо structметод може допомогти управляти конфліктом імен, що лежить в основі проблема межкомпонентное зв'язку яких використання глобал вводять особливо в сучасних багатопотокових застосуваннях, все ще існує.