...известный специалист по программированию - Александр Степанов, который работая в Bell Labs участвовал в создании C++ вместе c Бьерном Страуструпом, а впоследствии, уже по приглашению в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП, в частности он пишет: "Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг - из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле".
Цитировалось изначально по Lurkmore, я же здесь привожу расширенный фрагмент с блога Игоря Савчука. Вообще, вдумчивое прочтение вызвало бурю эмоций, но приближаться к оценке в стиле Lurkmore не очень хочется, так что поделюсь своими соображениями в более сдержанной манере. Не то, чтобы я хотел начать по данному поводу масштабную дискуссию, просто практически каждое слово в приведенной цитате расходится с моим мировоззрением, а когда в процессе своей размеренной жизни натыкаешься на что-то, что идет ну совсем с пониманием этой жизни вразрез, это что-то, выражаясь специфическим языком сильно "доставляет". Итак...
Как и во многих других случаях точка зрения автора имеет право на существование, но не является единственно верной. В ней можно усмотреть явную ошибку с позиционированием, скажем так, "классов относительно математики" - приравнивание классов к аксиомам. Не совсем понятно на чем вообще базируется аналогия - это сравнение, на мой взгляд, достойно "астронавта от архитектуры" как их называет Спольски (Спольски Дж. "Джоэл о программировании..." - СПб.: Символ-плюс, 2008). Прибытие к неприятным выводам происходит при поддержке весьма неоднозначного сравнения.
Если уж на то пошло, то классы в ООП разумнее сравнить в математике с множествами простых, вещественных, положительных и прочих чисел, применимых к этим числам операций и так далее (это я как математик говорю), а не с аксиомами.
Заявление по поводу начала в математике с доказательств странно само по себе - начинается в математике с фактов, продолжается абстракциями, то есть с выбора того, как мы что обозначаем и какие действия можем выполнять над теми или иными (внимание!) объектами... ООП проще и логичнее сравнить со всей формальной системой записи математических задач и выражений.
По поводу ущербности ООП в принципе не могу согласиться тоже. В частности, я занимаюсь имитационными (симуляционным) компьютерным моделированием в системе Pilgrim 5, где существует набор узлов типа "Очередь", "Сервер", "Склад" и т.д. (один уровень абстракции), на которые при составлении каждой конкретной модели ты смотришь как на "Менеджера", "Датчик", "Стопку бумаг", "Склад книг" и так далее (второй уровень абстракции) - как тут без ООП не могу себе даже представить и, честно говоря, альтернативы кажутся мне ужасными и темными.
Рефакторинг действительно популярен в ООП, тут спору нет (более или менее, чем в структурном программировании, - не могу сказать, но интуиция подсказывает, что дело здесь вообще не в парадигме, а в качестве изначального кода), но это не следствие неправильности или сложности парадигмы, а следствие сложности ее применения/воплощения. Понять, что такое классы и объекты не сложно, сложно подобрать подходящие для каждого конкретного случая абстракции, иерархии и определить "правильные" способы взаимодействия между элементами, то есть интерфейс - это процесс уж очень творческий. Кстати, ссылка на рефакторинг в связке с тезисом об изменчивости интерфейса вообще неуместна, поскольку согласно Фаулеру (Фаулер М. "Рефакторинг: улучшение существующего кода" - СПб.: Символ-Плюс, 2008):
Рефакторинг (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения (то есть именно интерфейса - прим. мое) и имеющий целью облегчить понимание её работы.
Я не являюсь крупным специалистом по ООП в общем, - только в частности, но мое мнение таково: все проблемы и критика связаны с тем, что людей зачастую учат сначала программировать без ООП, а зтем уже "натягивают" их сложившиеся представления на новую парадигму - причем зачастую это делают преподаватели, пришедшие к ней тем же путем.
Вот в ИТ-образовании я, действительно, специалист значительно повыше среднего, поэтому знаю, что говорю. Обучение ООП зачастую начинается с его трех китов-постулатов, а не с того, что есть классы и объекты, удачные классы и объекты, а также удачное ПО, созданное на их основе. Прибегая вновь к сравнению с математикой - это то же самое, что в 1-ом классе, не рассказывая про цифры и +/-, начинать обучение со слов "Создавая свою формальную знаковую систему, нужно иметь в виду..."
Еще пример из собственного опыта: когда мы изучали Turbo Vision (TV) на втором курсе (1996 год), мы изучали его не в рамках ООП, а в качестве некоего "средства, облегчающего построение интерфейсов", где "интерфейс уже как бы есть, и нужно только указать, чем твой будет отличаться от стандартного". Логичнее было бы начинать изучение с тезиса: "Смотрите, какую штуку из классов и объектов сварганили, как много она может вам дать, и как с ней удобно работать - вы можете научиться строить такие же удачные (или неудачные - в TV было множество проблем) иерархии и библиотеки из классов и объектов предметной области".
Если взять человека, который пришел к ООП "правильным" путем, я думаю, что для него приведенный вначале фрагмент с проблемами будет не то что спорен, непонятен он будет в силу надуманности и смехотворности проблем.
Комментариев нет:
Отправить комментарий