Вообще на практике наследование используется не сказать чтобы так часто, даже не смотря на то, что в большинстве случаев хорошие программисты заменяют его композицией. Чаще встречаются множественные реализации одного интерфейса, который в качестве зависимости указываются в клиентских классах. Что в свою очередь позволяет воспользоваться вторым столпом ООП — полиморфизмом. Который позволяет передавать разные реализации зависимостей в клиентский код. Из-за того, что передаваемые зависимости имеют одинаковый интерфейс, клиенту (зависящему от интерфейса) всё равно какой к нему попал объект и это позволяет программисту изменять, во время выполнения программы то, каким способом (какой реализацией интерфейса) будет решена окончательная задача. Говоря об ООП, также нельзя не упомянуть об инкапсуляции. Это важнейший элемент ООП, который предоставляет возможность создавать абстракции, чтобы скрыть низкоуровневые детали реализации снижая сложность разработки. Детали реализации скрываются модификаторами доступа к методам, такими как private и protected. Создавая классы, надо создавать их так, чтобы их интерфейсы (доступные public методы) предоставляли согласованную абстракцию, иначе это уже не ООП(!). Например, давайте предположим, что мы разрабатываем программу, управляющую системой охлаждения ядерного реактора. Тогда согласованная абстракция интерфейса может выглядеть следующим образом.
CoolingSystem::getTemperature()
CoolingSystem::SetCirculationRate($rate)
CoolingSystem::OpenValve($valveNumber)
CoolingSystem::CloseValve($valveNumber)
Благодаря краткому выразительному интерфейсу образующему согласованную абстракцию, мы можем работать с системой охлаждения реактора, не имея ни малейшего представления о низкоуровневых деталях реализации, характерных для выбранной технологии. Использование абстракций, позволяет существенно снизить сложность разрабатываемой системы. А борьба со сложностью является главным техническим императивом разработки. Вот ещё несколько примеров согласованных абстракций:
Система регулирования скорости:
- Задать скорость
- Получить текущие параметры
- Восстановить предыдущее значение скорости
- Отключить систему
Кофемолка:
- Включить
- Выключить
- Задать скорость
- Начать перемалывание кофе
- Прекратить перемалывание кофе
Топливный бак:
- Заполнить топливный бак
- Слить топливо
- Получить емкость топливного бака
- Получить статус топливного бака
Фонарь:
- Включить
- Выключить
Проектируя интерфейс объекта объявляйте публичными только те методы, которые нужны клиенту для управления, скрывая всё остальное. В результате у вас должны получаться чёрные ящики, о устройстве которых можно забыть после того как код класса дописан. Этот подход позволяет существенно снизить сложность разрабатываемой системы.
aPiks
Наверное, лучше что-то подобное публиковать на Java Rush, но тут не стоило.
sshikov
С какого момента вот это:
CoolingSystem::OpenValve($valveNumber)
вдруг стало для Java Rush?