Почему ООП

Объектно-ориентированный подход.

Да. Не программирование, а именно подход.
Подход включает в себя и программирование тоже.
Научившись применять объектно-ориентированное программирование я невольно начал использовать усвоенные принципы и в обычной жизни.
Мышление из плоского и линейного превращалось постепенно, по мере изучения ООП в многослойное и объемное.
Вдруг заиграли совершенно иные грани взаимодействия между людьми, между коллегами в коллективе и в других, совсем далеких от программирования вещах.
Но все началось именно с Объектно-Ориентированного Программирования.
История ООП началась 1960х годах в Массачусетском технологическом институте.
Я не буду здесь описывать всю историю возникновения ООП в мире. Это можно прочитать в wikipedia и в других статьях.
Для меня же, это началось примерно в 1992 году, когда я начал изучать TurboPascal.
При первом ознакомлении с основами ООП я ничего не понял.
Ну классы, ну объекты, каша. По сравнению с простым структурным программированием, которым я на тот момент занимался уже больше шести лет, все это казалось совершенно ненужным усложнением и так достаточно сложных вещей.
Зачем городить лишние сложности, когда можно просто создавать нужные модули и процедуры?.. А если учесть, что кроме самого чистого программирования нужно было еще решать попутно совершенно другие проблемы освоения новых сред IDE, администрирования, новых технологий и подходов, то привносимая сложность воспринималась мной как что-то чуждое и лишнее, хотя и жутко интересное. Тогда не было интернета и не было хороших книг, по которым можно было бы изучить теорию ООП, не было коллег, которые могли бы поделиться своими знаниями, и, самое главное, не было задач, которые можно было бы решить в полной мере используя ООП. Были только достаточно тривиальные задачи, которые и так просто решались структурным программированием.
Ложку дегтя в мое понимание ООП внес язык Actor . Тогда только-только появилась OC Windows и было жутко интересно написать программу с использованием новых технологий. Но по причине полного отсутствия документации на русском языке (английский я тогда знал совсем слабо) и по причине моей неготовности воспринять новые идеи (а, возможно, просто из-за лени) то, что я пытался сделать было совершенно невнятным и далеким от жизни.
И так я продолжал жить в структурном-процедурном программировании еще очень долго. Аж до 2000 года! Нельзя сказать, что за это время я совсем не изучал ООП. Изучал, конечно! Литературы по ООП становилось все больше, появлялись новые среды программирования, новые задачи. Эта тема волновала меня все сильнее и я ее уже применял в жизни, но, как я понимаю сейчас, это были попытки весьма далекие от совершенства.
Жизнь шла. В 2000 году я начинаю работать с Axapta тогда еще Damgaard, потом MS. Эта ERP имеет свой собственный язык разработки X++, который является полностью объектно-ориентированным. И, о чудо! Мне попадается (наконец-то!) вменяемая книга об ООП «Объектно-ориентированное программирование в действии» Автор: Тимоти Бадд.
И вот тут пошел настоящий снос крыши и полное изменение мышления.
Сложились сразу все факторы —
1. Объектно-ориентированная среда разработки
2. Объектно-ориентированный язык
3. Прекрасная теоретическая подготовка
4. Наличие сложных задач, требующих как раз Объектно-Ориентированного Программирования.
5. Наличие большого количества уже имеющихся примеров реализации, с помощью которых можно было посмотреть как это все работает в жизни
6. Большой опыт программирования, который способствовал глубинному пониманию происходящих процессов и позволял понимать последствия принятия тех или иных решений.
7. Не скажу, что были хорошие учителя, но опыт общения со своими коллегами по работе тоже позволял глубже погрузиться в среду Объектно-Ориентированного Подхода.

Тогда образ мыслей у меня стал меняться. Не все сразу стало ясно и понятно. Научиться ООП за один месяц невозможно. Даже за два месяца невозможно. Тем более, проработав до этого десять лет на процедурном программировании.
Нет. Конечно, выучить основные принципы и понять как вызывать методы объекта какого-либо класса достаточно просто. Тем более, когда среда имеет IntelliSense и позволяет тупо выбирать нужные, уже реализованные до тебя свойства и методы.
Использование же ООП в полном объеме требует полной перестройки своего мышления с плоского (если-то) на объемное (если может быть — то будет это или это или это или …). Разница огромная!
И вот, когда ты начинаешь понимать ЗАЧЕМ до тебя сделана эта куча классов, когда ты перестаешь удивляться совершенно пустому методу в базовом классе, который совершенно кажется и не нужен, когда метод, состоящий из 20 (да да, из двадцати!) строк кажется тебе уже совершенным монстром, непонятно что делающим, вот только тогда ты можешь сказать, что ты понял ОСНОВЫ ООП.
У меня на это ушел почти год.
Через год работы в объектно-ориентированной среде я уже мог понять всё, что хотел сказать тот или иной разработчик своим кодом. Не просто понять что делает какой-то код, это может сделать даже студент (правда, не всякий), а понять способ мышления программиста, который делал эту часть программы, понять смысл происходящего, и, наконец, оценить красоту построенной структуры классов или удивиться уродливости архитектурного решения.
Освоив основы объектно-ориентированного программирования я уже стал применять его принципы в полном объеме. Это мне тогда так казалось. На самом деле, между тем, что ты начал все понимать, и тем, что ты начал все что узнал применять, огромная разница! Понимание уже сделанных решений не ведет автоматически к идеальному проектированию новых решений. К величайшему сожалению.
И только спустя года два или даже три, я могу сказать, что я уже достиг той квалификации именно Архитектора с большой буквы, который может предложить и реализовать адекватную структуру классов для решения той или иной сложной задачи. Или обойтись и без всяких структур, если задачка тривиальная. На освоение этих принципов уже Объектно-Ориентированного Подхода (не программирования!) у меня ушло очень много времени, сил и большого количества громадных по своей структуре задач.

Сейчас в сети много публикаций, содержащих критику ООП. На форумах разворачиваются бои между сторонниками различных парадигм программирования .
На своем долгом программерском веку я попробовал почти все. За редким исключением.
В каждом подходе есть свои плюсы и свои минусы.
Исходя из моего опыта, я могу сказать, что в первую очередь нужно смотреть на поставленную перед разработчиком задачу. В соответствии со сложностью задачи и имеющихся в наличии ресурсов (обязательно!) уже нужно выбирать тот или иной подход.
У меня был такой случай, когда я не учел имеющийся в тот момент ресурс — квалификацию программиста, который будет реализовывать поставленную задачу (это была девушка, которая даже понаслышке не знала что такое ООП, пришла из FoxPro). Я сделал ей нормальное архитектурное решение, описал необходимую структуру классов и отдал в разработку… Когда я увидел то, что она реализовала, мне захотелось плакать. Да. Классы были сделаны. Даже методы были сделаны, те, что у меня были в архитектурном решении. Но вся функциональность была написана в ОДНОМ методе базового класса. Этот метод содержал безумное количество строк (уже не помню, но точно больше тысячи) и на тот момент делал то, что было написано в требованиях к задаче. То, что задача может изменяться и дополняться об этом девочка не думала. Ее решение было полностью сделано в структурном стиле программирования. Это был мой провал как организатора процесса разработки. Пришлось обучать девушку ООП и отправлять всю задачу на переделку.
С тех пор было много решений хороших и разных. Были сложные, были простые, были решения, которые внедрялись с первого раза и работают до сих пор, а бывали и такие, которые не доживали даже до стадии разработки. По мере увеличения количества реализованных задач и видя результаты своих решений, увеличивался набор тех приемов, которые я могу использовать в своей работе и повышается надежность реализованных мной задач.
Несмотря на большое количество изученных и применяемых мной средств, подходов и технологий, я все больше склоняюсь перед волшебством объектно-ориентированного подхода.
Ни один другой подход не дает такого полного вИдения проблемы. Возможность абстрагироваться от неважных в решении моментов, выделить основные общие требования, построить оптимальный путь решения, задать необходимые условия выполнения — все это имманентно присуще ООП.
Когда я полностью освоил объектно-ориентированное программирование и стал ДУМАТЬ с использованием объектно-ориентированного подхода, я вдруг заметил, что применяю эти способы решения проблем не только в программировании. Ведь, по сути, любую проблему можно рассмотреть с точки зрения объектов(субъектов) участвующих в конкретной ситуации. И вот, у меня в голове автоматически срабатывает объектно-ориентированный подход. Автоматически отсекаются неважные моменты, которые можно решить в дальнейшем (навесить бантики), выделяется основная структура взаимодействия акторов и уже на этом этапе появляется возможность анализировать способы разрешения той или иной ситуации…
Как при решении сложной головоломки. Сначала не понятно что и как, а потом вдруг становится все просто и ясно и появляется мысль «Как же я раньше не мог догадаться!».

Поэтому свой сайт я назвал «Про ООП»
Здесь я буду публиковать статьи не только по объектно-ориентированному программированию, но и свои мысли и решения по совершенно разным аспектам программирования и жизни вообще.
Приятного вам чтения.


Оставить комментарий