Простыми словами
Потребитель модуля должен знать, что модуль умеет делать, но не обязан зависеть от того, как это устроено внутри. Это похоже на бытовой прибор: кнопки остаются теми же, даже если производитель полностью переделал внутреннюю схему. Такой подход позволяет менять реализацию локально и не заставлять соседние части программы переписывать свой код.
Механизм действия
Сначала проверяют, есть ли исходное условие из определения. Затем смотрят, как оно влияет на структуру компонентов, потоки данных, ограничения и действия участников. Если эту связь не удаётся наблюдать, принцип не стоит использовать как готовое объяснение.
Пример в работе
В задаче «API» сразу применить привычное решение и назвать происходящее «Сокрытие информации», не проверив, действительно ли работает этот механизм. Так можно улучшить один симптом и пропустить основную причину.
Использовать «Сокрытие информации» как гипотезу: сначала определить границы ситуации и исходное состояние, затем менять только то, что связано с проверяемым механизмом, и смотреть на результат.
Ограничения
«Сокрытие информации» объясняет только часть происходящего в области «Архитектура ПО». Сам принцип не говорит, насколько сильным будет эффект в вашем случае, и не заменяет измерения. При другом масштабе, среде или временном горизонте результат может отличаться.
Источник
David L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”, 1972.