Основы ООП: абстракция

Мы часто используем в обычной жизни обобщающие понятия для передачи сути информации, не вдаваясь в детали. Например, на вопрос "как ты сюда добрался", человек может коротко ответить: "на машине". И для всех будет ясно, что речь о средстве передвижения на 4-х колесах, с двигателем и пассажирским кузовом. Какой конкретно марки была машина, какого цвета или года выпуска — нам не важно.

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

Таким образом, абстракция заключается в предоставлении простого программного интерфейса, который оставляет скрытыми все сложности и частности реализации.

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

Реализация, как правило, использует для хранения информации переменные или массивы, принадлежащие объекту (согласно описанию класса). Для них также имеется особое название — поля (этот термин происходит оттого, что свойства объектов часто связаны соотношением 1:1 с полями ввода в пользовательском интерфейсе или с полями в базах данных, где может сохраняться актуальное состояние объекта для возможности его восстановления при следующем запуске программы).

Поля и методы, хотя и описываются в классе, но относятся к конкретному объекту: под каждый экземпляр выделен собственный набор переменных, они имеют значения, независимые от состояния других объектов, и методы работают с полями своего экземпляра.

Интерфейс и реализация должны быть независимы. При желании одну реализацию должно быть легко заменить на другую без всякого влияния на программный интерфейс. Также очень важно проектировать интерфейс исходя из требований конкретной задачи, а не подгонять под реализацию. Разработчик класса должен уметь рассматривать свое творение с двух точек зрения: 1) как автор внутренних алгоритмов и структур данных; 2) как потенциальный придирчивый заказчик, который использует класс как "черный ящик", и его панелью управления является интерфейс. Рекомендуется начинать разработку класса с продумывания программного интерфейса, до поиска и выбора методов реализации.