Популярно об объектно-ориентированном программировании (ПООП)
Однажды я проснулся среди ночи в горячечном бреду и понял, что я не Бьерн Страуструп и даже не Гради Буч. И после этого я, как мало-мальски честный человек, просто не мог не написать вот ЭТО...
Обычно светила, знатоки Объектного программирования, начинают с основных терминов. К счастью, я не светило, и мне это никоим образом не грозит. Поэтому начну я именно с основных терминов.
Итак, что же такое Объект? Вслушаемся в звучание этого слова в разных контекстах. "Если мне позвонят, я на Объекте..."; "Неопознанный летающий объект вошел в плотные слои..." Не правда ли, звучит как-то загадочно и таинственно? И как все просто! Если вы прочитали где-нибудь определение, что "Объект - это некая сущность, материальная структура, инкапсулирующая в себе свойства, информационные закономерности и методы воздействия на внешний мир", то не верьте. Ни-ни! Автор просто завидует вашему крепкому сну и нормальности вашей психики. Объект - это просто Объект, и ничто иное.
На этом стойком, логически законченном определении можно было бы закруглиться, даже не начав. И тем самым сэкономить кучу бумаги и машинного времени. Но... как же быть с целой армией фанатов ООП, одурманенных гнилой идеологией "отцов" объектного анализа и объектного же программирования? Будучи человеком слабым и отчасти милосердным, я вынужден прибегнуть к неблагодарному занятию разжевывания общеизвестных терминов ООП для людей впечатлительных, но без нарушений высшей нервной деятельности.
Смею надеяться, что с термином "Объект" я исчерпывающе разобрался. Тот, кому дорого его и машинное время, кто трезво смотрит на жизнь и быстро печатает на клавиатуре, сейчас уже понял, что понятие объекта чуждо истинному ценителю ночных бдений у дисплея.
Однако остаются иные термины, среди которых часто слышится выражение "Объектный класс", "класс Объекта". Не стану плодить тавтологий типа "Класс - это Класс", а лишь позволю себе напомнить вам вашу юность. Не так давно все мы были пассажирами Совка, в котором, как известно, среднее образование было обязательным. Группы детей, подавленных коммунальной идеологией, формировались произвольно и хаотично в классы, причем тогда и речи быть не могло о соответствии типов. Это - типичный пример ярко выраженного структурного программирования личности, директивного управления поведением беспорядочного набора неизвестных величин (*). Так вот, класс - это набор объектов, имеющих множество общих признаков, и как минимум, они должны быть совместимы по типам. Позже я напугаю вас непотребным словом "полиморфизм" и докажу, что оно не всегда является ругательным, а пока лишь замечу, что каждый приличный объект имеет свой собственный тип, его потомки имеют другой тип, но совместимы со своим папашей (как теперь говорят, "предком").
А еще говорят, что сын за отца не отвечает! Отвечает, еще как отвечает, а заодно и наследует все его недостатки.
Если уж я ударился в вопросы наследования, то нелишне поправиться, пока не поздно. Объект по отношению к потомку в компьютерном мире - скорее женского пола, поскольку программисты (в большинстве своем) являются мужиками. Потомок - читай: "дочерний объект" - наследует от родителей-объектов (да-да, программист тоже суть объект самого среднего класса) все недостатки, свойства и методы работы. Конкретно: от мамы - свойства и методы работы, от папы - методы работы и свойства, и от них обоих - недостатки. Правда, встречаются извращенцы (не в обиду им будет сказано), которые способствуют размножению объектов в Си. Так вот эти наСИльники практикуют групповое размножение и подключают сюда друзей (friend classes). По натуре своей я консерватор, поэтому такие развлечения считаю неприемлемыми и недостойными светлого имени совкового опыхакера (**). Не исправит меня даже могила. К тому же, она может оказаться братской.
Но хватит о грустном. Скажу пару слов о противном.
Давеча я упоминал какие-то свойства и методы. О недостатках разглагольствовать бессмысленно, так как любой мало-мальски натасканный на Бейсик начихакер знает, что недостатки программирования классифицируются следующим образом: синтах ЕГГОГ, ЕГГОГ при компиляции, рун-тайм ЕГГОГ (или АВОСТ по-старому), страшные ZERODIVIDE и GPF, и более тонкие: баг, глюк и плохая погода.
Что же такое свойства (они же "пропертя")? Вы это у меня спрашиваете? И не стыдно вам задаваться таким вопросом при людях? Вы же сами просто напичканы свойствами и атрибутами. Взять, например, зарплату.
Свойство ли это, атрибут или состояние души? Представьте, что вам повысили зарплату, или, говоря проще, произошел инкремент значения атрибута "зарплата". Что при этом изменилось? Если, придя домой, вы замечаете, что супруга реагирует адекватно (ластится, пытается получше накормить и обласкать, etc.), значит, зарплата - это свойство (проперть) объекта вашего типа. Изменение значения свойства повлекло за собой изменение алгоритма взаимодействия с внешним миром и vice versa. Если же при этом ничего ни на душе, ни в вашей личной жизни не меняется, и необходимо самостоятельно (сиречь вручную) восстанавливать status quo в семейной ячейке - знайте, что для объектов вашего типа зарплата является всего лишь атрибутом, полем объекта "ВЫ". В этом случае инкремент атрибута "зарплата" не отражается мгновенно на состоянии объекта "ВЫ". Необходимо применять некоторые методы, чтобы изменить положение вещей... Уж вы меня извините, но описание этих методов выходит за рамки данной статьи.
Видите, как сложно, зыбко и неоднозначно? Видите? И добровольно погребаете себя под ворохом описаний объектных классов и отладочных листингов? Да вы, батенька, это... пойдите, пива попейте (***).
А чтобы окончательно убедить вас во вредности и несостоятельности объектного программирования как идеи, мне нелишне будет упомянуть ругательные выражения в применении к объектной ориентации.
Как вы думаете, что может обозначать слово "полиморфизм"? Как и все прочие "измы", этот термин изначально несет поганый, неприличный, ругательный смысл. Однако, как бывает в научных кругах, в ругательство вложили иное значение. Пока точно никто не знает, какое именно, но японские исследователи достоверно показали, что слово это красивое, и в его звучание заложен идеальный ритмический рисунок. Лексически термин "полиморфизм" распадается на приставку "поли", что значит "много", и "морфо", что значит "разный", "изменять", "преобразование" (ненужное зачеркнуть). Таким образом, термин "полиморфизм" можно понимать двояко, трояко и даже четверояко: "многоразличие", "мультиизменчивость", "политрансформация", и наконец, "сильное коверкание". Это лишний раз доказывает превосходство разума над такими архаичными науками, как лексика, поскольку объектный программист, выговаривая слово "полиморфизм", имеет в виду всего лишь возможность перекрытия виртуальных методов без изменения исходного кода объекта.
"Да, но что же такое "виртуальный"?" - спросите вы. И будете правы, потому что этого не знает никто. Кроме меня (****). По секрету делюсь: "виртуальный" - от фамилии создателя языка Паскаль Никлауса Вирта. Слово это означает "фиктивный", "несуществующий", а точнее, "существующий лишь в воспаленном воображении программиста". Произнося фразу "перекрою-ка я тут виртуальный метод...", программер попросту расписывается в своей беспомощности перед структурой объекта. Этот горе-кодировщик разбалован настолько, что не в состоянии переписать с нуля мало-мальский код (строк хотя бы тысячи полторы исходника). Нет, он обязательно наплодит виртуальных методов и в результате получит красивый пшик. Мне возразят, что пшик этот таки будет работать. Да, таки будет! Но несчастный пользователь объекта с перекрытыми в нем виртуальными методами постоянно ждет от него (от объекта) любого подвоха.
Посему - плюньте на объекты! И вообще - пишите на ассемблере, чтобы не возникало соблазна "перекрывать виртуальные методы". Запомните хорошенько: каждая подпрограмма - суть метод объекта "программа", и где гарантия, что с течением времени этот метод не станет виртуальным? Ведь следом виртуальными станут все переменные, входные и выходные данные, а также сама программа. И тогда разгневанный юзер идет и виртуализирует автора программы ноутбуком по фейсу, навеличивая его при этом "полиморфным абстрактным классом с инкапсулированной виртуальностью" и другими нехорошими словами.
А есть ли способ избежать всех этих кошмаров, спросите вы? Есть, отвечу я! Пишите программы без подпрограмм вовсе. Чем больше размер, тем быстрее будет работать - об этом знает всякий, кто работал когда-либо в среде операционной системы Windows(tm) (от трех и выше). Не знаете ассемблера - пишите на Бейсике, это почти одно и то же. А еще лучше - не пишите программ! Читайте чужие (*****)...
* * *
(*) Прошу извинить за трехэтажные предложения. Словоблудие у меня в крови (назад).
(**) "Опыхакер" и далее "начихакер" - суть термины, описываемые в одной из моих предыдущих публикаций. Кратко: начихакер - начинающий хакер, он же юзер, ламер и (или) зопух; опыхакер - соответственно, опытный хакер, к которым причисляются кодеры (системщики и прикладушники), жестянщики, а также некоторые из племени СисОпов (назад).
(***) Сам автор этих строк IMHO пристрастия к пиву не разделяет и всячески порицает его безудержное поглощение. Но если вам это нравится - на здоровье (назад)!
(****) Медицинская справка о мании величия у автора этих строк имеется и может быть представлена интересующимся (назад).
(*****) В бесполезности написания любых программ автор сам неоднократно убеждался, чего и вам желает (назад).
* * *
Загружены по самые регистры ? Самое время послушать анекдотик!