Сразу сообщаю что1. Я "сторонник" ООП
2. Мое глубокое убеждение в том, что каждому инструменту своя задача
Тем не менее, почему ООП, или почему его считают "сложным", "бюрократичным", "махиной" и проч?
А потому что видимо мало кто понимает зачем оно нужно и что конкретно оно дает.
Обьясняю на примере. Я и сам нечто подобное думал написать, но сегодня попался на глаза коммент к статье Джоэла, один в один... Можно считать плагиатом.
Итак, я решаю написать нечто на старом добром С и знать не хочу об ООП. Предположим, мне нужен линкованый список, и у меня в руках нет готовой библиотеки. Естественно, я ввожу нужные переменные и пишу ряд функций типа add(), get(), head(), tail(), count(), и проч. Программа пишется себе пишется, и файлик становится нехилым. Конечно же, я делаю программу модульной, то есть выношу список в отдельный модуль. Далее, оказывается, нужны также хешмап и дерево. Соответственно, они попадают в модули map.c, tree.c Это есть гут, но теперь я начинаю путаться в вызовах методов, ведь каждая из этих коллекций имеет похожие методы add(), remove() и так далее. Выход например такой: переназвать методы в addToTree(), addToMap(), addToLinkedList(). Трудимся, и перелопачиваем все эти файлы.
Далее, оказывается нужен также особый список, содержащий только элементы определенного типа. Нужно создавать отдельный модуль LinkedStringList и методом копипаста переносить в него содержимое предыдущего файла. Естественно, кое где я забываю подправить код, что стоит мне в дальнейшем многих часов дебаггинга.
Далее, вроде все ок, но мне нужно провести поиск по нескольким коллекциям сразу. Простой код поиска в списке необходимо дублировать и для мапа и для дерева, меняя в каждом случае только вызов методов.
Другая проблема в том, я решаю использовать хешмап, написанный Васей (он круче) и по незнанию меняю пару переменных из своего кода, тогда как они нужны самому мапу и ни в коей мере не мне. Упс - хешмап оказывается очень неэффективным! Какого спрашивается? Денек - и ответ ясен, не нужно было трогать этих переменных.
Теперь посмотрим, можно ли упростить наш кот? Можно. Назовем модуль - классом, и создадим объект этого класса. Тогда решается проблема с названиями: вместо addToTree() мы пишем tree.add(), вместо addToStringLinkedList() мы пишем linkedList.add(). Проще? Проще.
Давайте также введем модификаторы доступа: переменные, не предназначенные для публики, объявим private, так что ни Вася, ни Петя не смогут из своего кода напрямую изменить их.
Наконец, введем наследование: объявив класс наследующим от другого класса, мы получаем весь его код без копипаста, и вдобавок можем перегружать определенные функции своими, т.е. подстраивать их под себя.
Но если два класса наследуют от одного и того же класса, они фактически являются этим классом, т.е. как минимум содержат те же методы. Следовательно, их можно рассматривать как класс-родитель. Теперь нам не нужно писать код отдельно для каждого типа коллекции, мы можем привести все эти коллекции к одному базовому типу и вместо трижды повторенного копипастом кода мы имеем один на всех.
Вот и получается, что ООП есть попросту упрощенное процедурное программирование. Конечно, ООП обросло своими специфическими вещеми и своей философией. И это позволило создать громадное количество библиотек за довольно небольшой промежуток времени. Заметьте, только ОО языки превратились в конце концов в "платформы" и "технологии". С помощью Java или C# можно написать любое высокоуровневое приложение - будь то десктоп, веб или корпоративное приложение, база данных или игра. Единственное что отброшено - это низкоуровневость (и скорость по сравнению с С и асмом). Но при настоящем развитии железа это и не нужно.
Хотя да, он же ООПшник 
