На этом шаге рассмотрим пример инкапсуляции.
Для иллюстрации принципа инкапсуляции вернемся к примеру гидропонного тепличного хозяйства. Одной из важнейших абстракций данной предметной области является обогреватель. Обогреватель представляет собой абстракцию низкого уровня, поэтому существуют только три целесообразных действия с этим объектом: включение, выключение и запрос состояния.
Интерфейс доступа (т.е. функции, которые класс может выполнить по требованию клиента, как показано на рис. 1) — это все, что клиенту следует знать о классе ОБОГРЕВАТЕЛЬ.
Рис.1. Абстракция Обогреватель
Обращаясь к внутреннему представлению класса ОБОГРЕВАТЕЛЬ, можно обнаружить совершенно другую картину. Предположим, что проектировщики решили разместить управляющие компьютеры вне теплицы (возможно, чтобы избежать слишком суровых климатических условий) и соединить их с датчиками и исполнительными механизмами с помощью линии последовательной передачи. Класс ОБОГРЕВАТЕЛЬ естественно реализовать с помощью электромеханических реле, управляющих мощностью, поступающей на каждый обогреватель и получающих сообщения по линиям последовательной передачи. Например, для включения обогревателя можно передать специальную командную строку, номер обогревателя и индикатор включения.
Предположим, что по какой-либо причине проектировщики изменили решение и вместо последовательных линий передачи решили использовать для управления запоминающее устройство. Интерфейс класса ОБОГРЕВАТЕЛЬ останется прежним, но его реализация кардинально изменится. В этом случае клиенты, которым доступен только интерфейс класса ОБОГРЕВАТЕЛЬ, не обнаружат никаких изменений. Это главная особенность инкапсуляции. Фактически, клиента не должна интересовать реализация класса, пока класс удовлетворяет его требованиям.
Разумная инкапсуляция должна локализовать проектные решения, которые могут измениться. По мере эволюции системы ее разработчики могут обнаружить, что какие-то операции выполняются недопустимо долго, а какие-то объекты занимают слишком много памяти. В таких ситуациях внутреннее представление объекта, как правило, изменяется, чтобы реализовать более эффективные алгоритмы или оптимизировать использование памяти, заменяя хранение данных их вычислением. Возможность изменения представления абстракции без ведома клиентов является важным преимуществом инкапсуляции.
Сокрытие информации является относительным понятием. То, что скрыто на одном уровне абстракции, может оказаться открытым на другом уровне. В принципе, реализацию объектов можно раскрыть. Правда, в большинстве случаев это происходит в соответствии с явным замыслом разработчика абстракции и только если разработчики классов-клиентов согласны на увеличение сложности.
Инкапсуляция не способна предотвратить ошибочные решения. Разумеется, ни один язык программирования не способен полностью закрыть доступ к реализации класса, хотя операционная система может перекрыть доступ к конкретному файлу, содержащему реализацию класса.
На следующем шаге рассмотрим третью составную часть объектной модели - модульность.
