Использование "черных ящиков" в борьбе со сложностью

Почему "черные ящики" - это хорошо.
Или в чем суть инкапсуляции.

В этом небольшом сообщении я хотел бы рассмотреть проблему сокрытия данных в масштабе крупной системы. Причем под "сокрытием" я понимаю не использование приватных полей/методов, а сокрытие логики, сокрытие того "как" что-то делается.

Если вы можете провести точную грань между тем "что" и "как", то это хорошая предпосылка создания качественного интерфейса, формирующего целостную абстракцию (о важности абстракций мы еще как-нибудь поговорим).

Почему вообще важен качественный интерфейс? Качественный интерфейс - это сигнал о том, что для конкретного элемента вашей сложной системы вы грамотно и, скорее всего, правильно определили область ответственности. Элемент(класс, если угодно, хотя и необязательно) делает одну вещь и делает это хорошо - вот это истинная цель, которая достойна преследования.

Но вернемся к тому "что" и "как". Именно это разделение открывает перед разработчиком компонента системы возможности сокрытия всех деталей, оставляя пользователю элемента лишь вкусную абстракцию, с которой приятно работать. Иными словами, "что" инкапсулирует все шаги, известные "как".

Но здесь есть один нюансик. Нередко, особенно на начальных порах, возникает иллюзия, что вы нашли границу между "что" и "как". Эта иллюзия в самом худшем случае приводит к появлению множественных геттеров(гет-методы) для защищенных данных(приватных полей) объекта.

Почему это плохо? 
Представьте себе: вы пришли в кабинет к стоматологу, который обладает всем необходимым для качественного лечения зуба. Но вместо того, чтобы садиться в удобное(хотя не всегда) кресло и не думать о том, что происходит в вашей ротовой полости, вы просите у стоматолога все инструменты, которые только можно запросить(через гет-методы), после чего стоматолог сам по себе(пошел пить чай), а вы с грудой инструментов и больным зубом - сами по себе.
Ситуация не из приятных. Было бы гораздо удобнее "попросить" стоматолога все сделать за вас, не вникая в детали его работы, ведь он в этой сфере мастер.

Именно таким образом в сложной системе и стоит создавать связи между слабозависимыми компонентами - один должен просить другого "что"-либо сделать, не вникая в детали того, "как" он это сделает, ведь главное - результат(а не участие в процессе).

В дальнейшем инкапсуляция деталей(информационных полей и большинства методов) поможет добавлять объектам новую ответственность, менять и улучшать старую, оставаясь при этом в пределах ответственного объекта.
Вы можете прийти к стоматологу, и он полечит ваш зуб разными способами, которым он научился где-то и как-то, но ваш запрос будет при этом оставаться неизменным - "полечите мне зуб!".

Грамотная инкапсуляция имеет мало общего с приватными и защищенными спецификаторами на уровне конкретных языков. Поэтому используйте инкапсуляцию грамотно.