Предпосылки становления ОО подхода (Рейтинг: +1)

Продолжая цикл статей об объектно-ориентированному подходу к организации программной архитектуры и мышлению, хотелось бы затронуть некоторые исторические эпизоды становления объектно-ориентированной мысли.
Рассмотрим становление процедурного подхода. Описание повторяющихся алгоритмов медленно переростает в необходимость повторного использования кода. Здесь на сцену выходят функции, которые позволяют вместить в себя алгоритм и впервые реализуются принцип "черного ящика". Действительно, функция позволят определить входные и выходные данные, а метод преобразования скрыть реализацию от пользователя. Другими словами, мы лишь знаем какие данные функция получает и что отдает функция, а ее работа нас не касается, и обычно, это позволяет упрощать разработку приложений за счет использования "черных ящиков". Помимо функций процедурный подход внес такие особенности как - тип данных (предпосылки ОО подхода) и библиотека (совокупность ориентированых на определенную область функций), эти нововведения позволили программистам использовать сторонние разработки в собственных решениях, что упростило и ускорело разработку программных решений.
ОО подход никак не заменяет принципов процедурного, а наоборот расширяет его. Именно из за этого, многие новички высказывают мнение - "Нет ничего объектно-ориентированного, с чем не может справится процедурный подход" - и это верно! Объекты и классы лишь позволяют более рационально использовать те самые переменные, функции и типы, что были со времен становления таких языков как фортран, си и паскаль, но новые конструкции позволяют использовать эти элементарные компоненты более эффективно. Представим сложную программу, включающую такие функции как подключение сторонних модулей, разделение прав доступа и гибкость в сопровождении. Все это отдельные, но взаимодействующие модули, с реализацией который процедурный подход слабо справляется, так как не позволяет скрывать переменные и методы работы с ними. Приходится помнить алгоритмы работы частей модуля и подстраивать другие субмодули к ним, это конечно приводит к некоторым границам возможности программиста, за которыми сопровождать и расширять такие программы будет очень сложно.
С другой стороны ООП позволяет облегчить разработку сложных архитектур за счет сокрытия данных. Представьте что бы разрабатываете каждый модуль через разработку простых модулей, содержащих несколько переменных и функций, это гораздо проще чем держать в голове все существующие в программе функции и переменые, ведь так? Вот в этом "сахар" ОО подхода, он позволяет закрыть модуль в классе, интерфейсе и композиции. Другими словами библиотека функций заменяется библиотекой модулей.