Изо дня в день меня беспокоит проблема использования чужих и своих классов и библиотек. Когда спустя некоторое время видишь, что в своем коде не хватает возможности переопределить поведение класса и это мешает, а еще хуже, когда инородная библиотека не выполняет заявленных ей задач, даже зная, где поправить и как тебя ограничивает код, который был написан в этой библиотеке без возможности переопределения. Данная статья структурирует подход инкапсуляции, который даст возможность не тратить лишнее время на создание велосипедов и спасти те усилия программистов, которые черные ящики используют и создают новые.
Инкапсуляция это искусство, а не просто черный ящик. Проблема есть – код, который нельзя поправить, переопределить, изменить и т.п. в том же проекте, где он используется. Все должно быть конфигурировано, переопределяться и изменяться. Универсальный солдат, которого вызывают в нужной ситуации и он спасает мир, а не ожидание рождения нового солдата. И решение это не исправление исходников библиотек, т.к. это трудоемкий процесс из-за простого отсутствия исходников. Легко сказать эти слова, но сложней понять, что они обозначают в языках программирования и как им соответствовать.
Я хочу сказать, что проблемы инкапсуляции есть, но они решаются. Можно взглянуть на черный ящик как уже готовый продукт, который используется для достижения цели, так и материал, из которого будет создаваться форма для достижения цели. Можно привести пример с художником, который использует краски для рисования и создает новые краски, т.е. конфигурирует краски для дальнейшего использования. Но если взять вместо красок и дать художнику пластилин, то желаемый цвет пластилина не получить, смешав пластилин (трудоемкий процесс). В данном случае пластилин уступает краскам.
Поэтому использование черного ящика можно поделить на две категории:
В случае внешних библиотек «готовые продукты» могут быть оправданы, но слишком большие ограничения могут вести программистов на дьявольскую дорожку. Цель же посредника, удобного скрытого ящика, конечно, помочь абстрагироваться от тонкостей реализации, но также дать возможность максимально конфигурировать его и, соответственно, расширить его использование.
Принципы, которые следует учитывать при создании библиотек, черных ящиков, для вновь использованного кода:
PS: Если тема интересна, то подготовлю примеры использования принципов OOSILA.
UPDATE: скрытый ящик => черный ящик
Инкапсуляция это искусство, а не просто черный ящик. Проблема есть – код, который нельзя поправить, переопределить, изменить и т.п. в том же проекте, где он используется. Все должно быть конфигурировано, переопределяться и изменяться. Универсальный солдат, которого вызывают в нужной ситуации и он спасает мир, а не ожидание рождения нового солдата. И решение это не исправление исходников библиотек, т.к. это трудоемкий процесс из-за простого отсутствия исходников. Легко сказать эти слова, но сложней понять, что они обозначают в языках программирования и как им соответствовать.
Я хочу сказать, что проблемы инкапсуляции есть, но они решаются. Можно взглянуть на черный ящик как уже готовый продукт, который используется для достижения цели, так и материал, из которого будет создаваться форма для достижения цели. Можно привести пример с художником, который использует краски для рисования и создает новые краски, т.е. конфигурирует краски для дальнейшего использования. Но если взять вместо красок и дать художнику пластилин, то желаемый цвет пластилина не получить, смешав пластилин (трудоемкий процесс). В данном случае пластилин уступает краскам.
Поэтому использование черного ящика можно поделить на две категории:
- Готовый продукт (актуальный для компании, которые получают прибыль для от продажи и поддержки продукта, MS, Oracle и т.п. По этой причине они и предоставляют классы, которые невозможно переконфигурировать)
- Посредник (актуальный для OpenSource компаний, но как не парадоксально забывают дать или не подозревают, что не дают возможность максимально конфигурировать свои классы)
В случае внешних библиотек «готовые продукты» могут быть оправданы, но слишком большие ограничения могут вести программистов на дьявольскую дорожку. Цель же посредника, удобного скрытого ящика, конечно, помочь абстрагироваться от тонкостей реализации, но также дать возможность максимально конфигурировать его и, соответственно, расширить его использование.
Принципы, которые следует учитывать при создании библиотек, черных ящиков, для вновь использованного кода:
- Overriden. Делать методы с оператором доступа, чтобы можно было переопределить методы. (как минимум protected, используйте очень редко уровень доступа меньше защищенного)
- Overload functions. Разнообразная сигнатура одних и тех же функций, уменьшать количество параметров в методах
- Static is Evil. Статичные переменные, функции зло, которое надо заменять на обычные переменные и функции
- Control Instances. Не создавать новые объекты, без возможности переопределения этого создания. Не используйте оператор new явно в коде, а использовать методы setters для этих объектов, фабрики создание объектов или функции создание объектов, которые переопределяются
- Last Version is Evil. Не использовать ключевое слово final для функции и классов. Позволять переопределять функции и классы
- Atomic. Вычленять на мелкие методы все логические единицы
PS: Если тема интересна, то подготовлю примеры использования принципов OOSILA.
UPDATE: скрытый ящик => черный ящик