10. Мінімізуйте глобальні і спільно використовуються дані
Спільне використання викликає суперечки і чвари. Уникайте спільного використання даних, особливо глобальних даних. Спільно використовувані дані посилюють зв'язність, що призводить до зниження сопровождаемоcті, а часто і продуктивності.
Обговорення
Це твердження носить більш загальний характер, ніж більш вузьке вимога рекомендації 18.
Слід уникати даних зі зовнішнім зв'язуванням в області видимості простору імен або представляють собою статичні члени класів. Їх застосування ускладнює логіку програми і призводить до тісного зв'язку між різними (і, що ще гірше, віддаленими) частинами програми. Спільно використовувані дані роблять менш ефективним тестування модулів, оскільки коректність фрагмента коду, що використовує загальні дані, обумовлена історією зміни цих даних, а крім того, обумовлює функціонування деякого, поки невідомого, коду, який буде використовувати ці дані пізніше.
Імена об'єктів в глобальному просторі імен призводять до його додаткового засмічення.
Якщо вам ніяк не обійтися без глобальних об'єктів, об'єктів в області видимості простору імен або статичних членів класів, переконайтеся в їх коректної ініціалізації. Порядок ініціалізації таких об'єктів з різних одиниць компіляції не визначений, тому для коректної роботи в такому випадку потрібні спеціальні методики (див. Прикладені посилання). Правила порядку ініціалізації досить складні, тому краще їх уникати; але якщо ви все ж змушені мати з ними справу, то повинні добре їх вивчити і використовувати дуже обережно.
Об'єкти, що знаходяться в області видимості просторів імен, статичні члени або спільно використовувані різними потоками або процесами, знижують рівень розпаралелювання в багатопоточних і багатопроцесорних середовищах, і часто є вузьким місцем з точки зору продуктивності і масштабованості (див. Рекомендацію 7). Намагайтеся позбутися від спільного використання даних; використовуйте замість нього кошти комунікації (наприклад, черга повідомлень).
Переважно забезпечити низьку зв'язність і мінімізувати взаємодія класів.
винятки
Такі засоби рівня програми, як cin. cout і cerr. є спеціалізованими і реалізуються спеціальним чином. Фабрика має підтримувати реєстр функцій, які повинні викликатися для створення даного типу, і такий реєстр зазвичай один на всю програму (тим не менш переважно, щоб він був внутрішнім об'єктом по відношенню до фабрики, а не глобальним спільно використовуваних об'єктом; см. Рекомендацію 11) .
Код, в якому об'єкт спільно використовується різними потоками, повинен забезпечити сериализацию звернень до такого об'єкта.
11. Приховування інформації
Чи не випускайте внутрішню інформацію за межі об'єкта, що забезпечує абстракцію.
Обговорення
Для мінімізації залежностей між викликає кодом, який працює з абстракцією, і реалізацією абстракції, внутрішні дані такої реалізації повинні бути приховані. В іншому випадку викликає код може звернутися до цієї інформації (або, що ще гірше, змінити її), і такий витік призначеної суто для внутрішнього використання інформація робить викликає код залежним від внутрішнього уявлення абстракції. Відкривати слід абстракції (переважно з відповідної предметної області, але, як мінімум, абстракцію get / set), а не дані.
Приховування інформації зменшує вартість проекту, терміни розробки та / або ризик двома основними шляхами.
Воно локалізує зміни. Приховування інформації знижує область "ефекту хвилі" внесеного зміни і, відповідно, його вартість.
Воно посилює інваріанти. Приховування інформації обмежує код, відповідальний за збереження (і, в разі помилки, за порушення) інваріантів програми (див. Рекомендацію 41).
Не дозволяйте "засвітитися" даними з будь-якого об'єкта, який забезпечує абстракцію (див. Також рекомендацію 10). Дані - всього лише одне з втілень абстракції, концептуальне стан. Якщо ви сконцентруєтеся на концепції, а не на її уявленнях, ви зможете запропонувати вдумливий інтерфейс, а "вилизати" реалізацію можна і пізніше - наприклад, шляхом застосування кешування замість обчислення "на льоту", або використання різних оптимізують уявлень (наприклад, полярних координат замість декартових).
Найпоширеніший приклад полягає в тому, що члени-дані класів ніколи не робляться доступними ззовні за допомогою специфікатор public (див. Рекомендацію 41) або за допомогою покажчиків або дескрипторів (див. Рекомендацію 42). Цей принцип в тій же мірі застосований і до великих сутностей - наприклад, таким, як бібліотеки, які також не повинні дозволяти доступ до внутрішньої інформації ззовні. Модулі і бібліотеки повинні надавати інтерфейси, які визначають абстракції і роботу з ними, і таким чином забезпечують більшу безпеку для викликає коду і меншу зв'язність, ніж при застосуванні спільно використовуваних даних.
винятки
Тестування коду часто вимагає можливості звернення до "нутрощів" тестованого класу або модуля.
Сукупності значень (struct в стилі С), які представляють собою просто набір даних без надання будь-яких абстракцій, не вимагають приховування своїх даних, які в цьому випадку є інтерфейсом (див. Рекомендацію 41).