Как модификаторы доступа тормозят развитие молодых специалистов

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

Дисклеймер. Эта статья не является призывом к действию и не утверждает, что есть единственный рассово верный способ сокрыть данные. Эта статья сделана с целью предложить читателю, возможно, новый взгляд на инкапсуляцию. Существует много ситуаций, где модификаторы доступа предпочтительней, однако это не повод умалчивать об интерфейсах.

В общем виде инкапсуляция определяется как средство сокрытия внутренней реализации объекта от клиента с целью сохранения целостности объекта и сокрытия сложности этой самой внутренней реализации.

Добиться такого сокрытия можно несколькими способами. Одним является использование модификаторов доступа, другим — использование интерфейсов (протоколов, заголовочных файлов, …). Есть и другие хитрые возможности, но статья не о них.

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

Видимость полей, обозначенный разными модификаторами доступа в Java.

В фрагменте кода ниже представлен класс с модификаторами доступа к методам и эквивалетные представления в виде интерфейсов.

public class ConsistentObject {     public void methodA() { /* ... */ }     protected void methodB() { /* ... */ }     void methodC() { /* ... */ }     private void methodD() { /* ... */ } }  public interface IPublicConsistentObject {     void methodA() { /* ... */ } } public interface IProtectedConsistentObject: IPublicConsistentObject {     void methodB() { /* ... */ } } public interface IDefaultConsistentObject: IProtectedConsistentObject {     void methodC() { /* ... */ } }

Протоколы имеют ряд преимуществ. Достаточно упомянуть то, что это основное средство реализации полиморфизма в ООП, которое доходит до новичков сильно позже, чем могло бы.

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

Такой код на C#

public class DataAccessObject {     private void readDataFromFixedSource() {         // ...     }      public byte[] getData() {         // ...     } }

будет эквивалентен такому по возможностям для клиента.

public class DataAccessObjectFactory {     public IDataAccessObject createNew() {         return new DataAccessObject();     } }  public interface IDataAccessObject {     byte[] getData(); }  class DataAccessObject: IDataAccessObject {     void readDataFromFixedSource() {         // ...     }      public byte[] getData() {         // ...     } }

Из-за существования модификаторов доступа, новички очень долго не узнают об интерфейсах. От этого они не пользуются настоящей мощью ООП. То есть происходит некоторая подмена понятий. Модификаторы доступа — несомненно атрибут ООП, но они же перетягивает одеяло с интерфейсов, которые раскрывают ООП гораздо сильнее.

Более того, интерфейсы заставляют осознанно выбирать какие возможности от объекта может получать какой клиент. То есть у нас есть возможность предоставить абсолютно несвязанные протоколы для разных клиентов, тогда как модификаторы не различают клиентов. Это большой плюс в пользу интерфейсов.