• Я не понимаю ООП

    Не боюсь признаться в том, что не понимаю ООП в том виде, что существует сейчас. То есть, я понимаю его формально, механически. Поскольку в проекте сплошное ООП, пишу классы наравне со всеми, но не вижу, какие проблемы это решает – наоборот, замечаю больше проблем. Вовсе не стараюсь закосить под Дейкстру, который говорил, что ООП – худшее, что придумали в Калифорнии (хотя факт, что сей ученый муж на моей стороне, неистово льстит).

    Защитники ООП-подхода говорят, что парадигма возникла в момент, когда стало чрезвычайно трудно поддерживать системы, написанные в процедурно-модульном стиле. Бизнес потребовал быструю разработку, назрел кризис роста индустрии. В ответ создали ООП. Важно понять, что абсолютно никто не мог сказать, во что это выльется. Примерно как вы не сможете сказать, чем закончится путешествие в сердце Африки. Люди хотели перемен, так вышло. Если бы придумали другую методологию, какой-нибудь ППО, мы бы писали сегодня на ППО.

    Хочу проговорить абзац выше другими словами. ООП вышло в лидеры по историческим причинам, а вовсе не потому, что это такая классная вещь. Кто-то показал презентации лучше, картинки ярче, будущее – счастливей. По тем же причинам фаворитами в своих областях стали христианство, коммунизм, Виндоуз и тд. Важно, что постепенно розовый экран осыпается, и мы должны подумать, что делать дальше.

    Сегодняшнее ООП далеко от первоначального замысла. Мы имеем объекты с методами, и каждый объект дергает методы других. В оригинальной задумке объекты ничего не знают о внутреннем устройстве соседей. Они шлют сообщения по идентификатору. Получив сообщение, объект с таким айди решает, как его обрабатывать (и стоит ли вообще), может послать что-то в ответ или далее по цепочке. Такая схема в Эрланге, но никак не в Джаве, Питоне, Си++ и других промышленных языка. Иначе говоря, сегодняшнее ООП является совсем не тем, что пытались разработать авторы.

    Рассмотрим на практике, что не так с ООП. Решим задачу о сложении чисел а и б. Приводить код в процедурном подходе, полагаю, нет смысла. Версия ООП:

    class Summator:
        a = None
        b = None
    
        def set_a(self, a):
            self.a = a
    
        def set_b(self, b):
            self.b = b
    
        def get_sum(self):
            return self.a + self.b
    
    sum = Summator()
    sum.set_a(2)
    sum.set_b(3)
    print sum.get_sum()
    

    Бросается в глаза размер кода. Защитники ООП скажут, что пример нелепый, потому что в ООП числа складываются операторами, а не классами. Отчасти верно, но в случае с классами кода всегда будет больше хотя бы потому, что помимо описания класса должен быть еще код, который создает класс и приводит к нужному состоянию. Класс – мертвая абстракция, которая оживает позже.

    Второй момент, ООП-подход обязует вызывать методы в определенном порядке. Этим он берет за горло мертвой хваткой. Если вызвать метод get_sum строкой выше или выкинуть set_a, суммирование упадет со странной ошибкой. Уйдет время, чтобы понять трейс. В реальных ситуациях шансы нарушить порядок методов возрастают. С функциями этого не случиться по определению. Невозможно вызвать вторую функцию, если она принимает словарь, полученный из первой функции.

    Даже если порядок методов соблюдается строго, поведение объекта невозможно предсказать в параллельном исполнении. Представьте, что каждый тред вызывает методы в нужном порядке, но обращение их к классу никак не согласовано. Потребуются доработки, чтобы класс работал правильно. Скорей всего, исправлять придется не сам класс, а код, который к нему обращается: создавать по экземпляру на тред, обкладывать локами. Сути это не меняет.

    Пример демонстрирует, что корректность программы зависит от состояния класса. Чем больше состояний, тем больше их комбинаций. Хороший программист стремиться свести состояния к минимуму. Так, функция

    def sum(a, b):
        return a + b
    

    лишена перечисленных недостатков. В ней нет состояния: два значения однозначно преобразуются в одно, поэтому функцию можно выполнять в тредах. К ней можно применить декоратор memoize, чтобы отдавать результат из оперативной памяти.

    Нас учат, что краеугольные камни ООП – инкапсуляция, наследование и полиморфизм. Все это есть в современных языках без привязки к ООП. Инкапсуляция – замыкание или словарь, где ключи хранят не только данные, но и функции для работы с ними. Весь Джаваскрипт так работает, еще Луа. В Кложе есть расширение протоколов: разработчик может добавить в существующий протокол свой тип данных. В Гоу разработчики наследуют структуры. Полиморфизм встроен в любой функциональный язык – Хаскел, Эрланг, Кложу.

    Говорят, ООП оперирует объектами, поэтому лучше отражает окружающий мир. Это видно в примерах, когда от класса Animal наследуют классы Cat и Dog. Потом заменяют метод голоса (мяу и гав) и т.д. Проблема в том, что мир вокруг нас неописуемо сложен. Природе потребовались миллионы лет, чтобы обуздать хаос и породить первый белковый комочек. Действительно считаете, что ООП может описать сложность окружающего мира?

    Проверьте код и убедитесь, что лишь малая часть классов отражает те сущности, которые есть в окружающем мире. В остальном это всевозможные менеджеры коннектов к БД, классы Utils, обертки логирования, то есть вещи, которые существуют только в голове программиста. Реальным миром здесь и пахнет.

    Объекты скрывают явное. Предположим, вызываю метод .get_data() у класса Foo. Знаю, что он унаследован от Bar, а тот от Baz. Как понять, из какого класса будет вызван метод? Был ли он переопределен Foo или Bar? Наоборот, когда вызываю функцию get_data() из модуля foo, ошибки быть не может – это именно та функция, не одноименная из модуля bar.

    Любопытно, что в природе нет наследования, какое видим в ООП. Набор генов формируется с учетом генов родителей, но затем особь становится полностью автономной и не зависит от предков. Вы видели, чтобы детеныш терял лапу от того, что папаша-самец попал в капкан? Или если мать сменит пол, то и ребенок тоже? Это же бред. В ООП происходит подобное – потомки прибиты гвоздями к предкам. При изменении цепочки где-то в середине изменения передаются по ниспадающей. В результате все ломается.

    Два класса, унаследованные от предка, обречены на страдания сиамских близнецов. Ни один не может претендовать на независимость. Согласно медицине, разделение сиамских близнецов – невероятно трудная задача, во всем мире считаные врачи делают эти операции. Разделение классов с наследниками протекает мучительно. Напротив, объединить функции в класс очень легко. Функция автономна по своей природе. Ей неважно, где находиться – на уровне модуля или класса. В следующий раз перед тем, как объявлять класс, начните с небольшого набора отдельных функций. Возможно, их окажется достаточно.

    Глобальный объект, на который ссылаемся через переменные self, this – ни что иное как читерство. Еще в школе рассказывают, что глобальные переменные – плохо и использовать лучше только для чтения. В ООП этот моветон гипертрофирован и возведен культ. Self – жирная глобальная переменная, методы меняют ее поля. Например, на уровне класса объявлено поле data = None. В каком-то методе автор невозбранно итерируется по нему как списку. Подразумевается, что перед этим будет вызван метод set_data, который заполнит поле data. Теперь представьте, что в объекте self двадцать полей. Как это контролировать?

    Конечно, с такой точкой зрения на ООП не избежать насмешек и споров с коллегами. Приведу типичные выпады и ответы.

    – Все современные языки исполнены в ООП, какой ни возьми.

    Неправда. Недавно появились Раст, Гоу, Кложа, Ним, где классов либо нет, либо они не являются центральной концепцией языка. Создатели поняли, что грамотные коллекции и структуры важней классов. В Гоу и Ним вызовы методов ни что иное, как синтаксический сахар. В Кложе классов и объектов нет, в Лиспах ООП строится поверх языка. В Тикле (TclTk) ООП-систем вообще пять.

    – Функциональные языки непригодны для промышленной разработки, только в академической среде.

    Неправда. Вакансии на Кложе, Хаскеле есть. Гуглите на Стековерфлоу. Для Скалы еще больше – проходите собеседование и работайте. К слову, обеспокоенность трудоустройством выдает нужду и играет на руку работодателю. Заказчик не заинтересован в вашем росте. Он хочет принять программиста за 50 тыс. руб. в месяц и держать на одном уровне много лет. Он горячо поддержит вас в том, что ООП – стабильность и уверенность, а ФП – удел академиков НИИ.

    – Все пишут на ООП, потому что альтернатив нет.

    Программированию всего 50-60 лет. Это меньше одной человеческой жизни, и не идет ни в какое сравнение с медициной или астрономией. В программировании все еще очень мало точек, на которые можно опираться как на непреложные истины подобно аксиомам в геометрии. Поэтому в исторических масштабах то, что видится трендом, окажется зигзагом кривой. Мыслите шире.

    – Ты писал на функциональном языке? Или только рассуждаешь?

    Да, веду личный проект на Кложе – большая нагрузка, БД, Редис, сетевые вызовы в социалные сети, прием платежей через Пейпал. Вначале мозг рвался, затем в голове щелкнуло и пришло понимание, как обходиться без изменяемых переменных, классов и того другого, без чего ООП-программисты себя и не мыслят.

    Надеюсь, эта статья поможет кому-то отказаться от подхода ООП-онли. Есть много парадигм, нужно знать если не все, то многие. Начните изучать функциональное программирование! Разнообразие парадигм сделает вас настоящим инженером.

    Комментарии из старого блога

    10/06/15 Корейша Виктор: Очень круто. У меня подобные мысли пару лет крутятся в голове. Но нет такого опыта на разных языках, что бы отвечать на выпады. Спасибо.

    10/06/15 Иван Гришаев: Джо Армстронг, создатель Эрганга, высказывается в похожем ключе: http://sotnyk.com/2012/05/19/pochemu-oop-polnyiy-otstoy/

    10/08/15 Павел Заикин: Каждому методу свои задачи. В чем-то хорош ООП в чем-то функциональный подход.

    Не бывает идеальных методов.

    10/08/15 Иван Гришаев: Осталось понять, кому какие =)

    10/08/15 Павел Заикин: ООП хорош там где нужно хранить состояния. Там где много однотипных сущностей с немножко разным подходом к выполнению алгоритмов. Там где нужно сделать часть данных недоступным для изменения из других частей программы. Да много где ООП хорош. Но ФП тоже хорош особенно для простых, линейных задач.

  • Шок, травмы, читать до конца!

    Когда начал работать в Емаксе, заметил, что болит большой палец на левой руке. Смотрю, а ноготь по правому краю весь стерт! Я ногти не грызу, стал думать, в чем дело. Оказалось, из-за частых нажимов на Альт (в Емаксе называется Meta или просто M) ноготь стерся о клавиатуру. Потом привык, конечно, но официально подтверждаю, что Емакс калечит руки!

    oh my hands

  • Удовольствие от X

    cover

    Классная книжица одного из лучших математиков. Важно, что этот математик умеет объяснять так, как учителям и не снилось. Очень душевно описывает основные разделы школьной программы: сложение натуральные числа, дроби, производные, пределы. Под каждый раздел приводит увлекательные примеры.

    Автор – весьма чувственный и увлеченный своим делом человек, поэтому в некоторых местах аж за душу берет. Рекомендую книгу тем, кто был не в ладах с математикой в школе. Книга поможет осознать то, что в свое время не смогли донести школьные учителя.

    Практическая польза в том, что в следующий раз, когда ребенок попросит помочь с математикой или геометрией, не будете бояться позора перед сыном или дочерью.

    Книжка выпущена в издательстве Иванов, Манн и Фербер, поэтому классный шрифт и чистая верстка. Красивая твердая обложка и незаменимая вещь – закладка-шнурочек. Кто-то думает, что это атавизм, но теперь, когда читаю книгу без такого шнурка, испытываю неудобства. Это же надо таскать листок-закладку. Словом, физические качества книги на высоте, как и содержание.

    Из минусов разве что плохо преобразованные черно-белые фотографии. В оригинале они цветные. Если печатать в ч\б, сперва нужно поправить уровни, иначе картинка получается темной. Короче, картинкам не хватает яркости. Ну и рисунки выполнены в немного примитивной манере.

    Вердикт – зачетная книжка.

  • Три вещи,

    которые не пристало делать мужчине, это:

    • читать фентези. Тащить гномов, эльфов и драконов во взрослую жизнь – это пиздец. Переболел в подростковом возрасте и хватит. Полно других полезных книг.
    • смотреть смешные картинки на Пикабу, Адми и др. Что, жизнь настолько уныла, что только картинки для школьников могут развеселить? Особый пиздец, когда смехуечки постят в Скайп.
    • поддерживать толерастию – защищать геев, лесби, веганов, православных, негров, просто тупых баб.

    Комментарии из старого блога

    09/28/15 Ананимас: Подхожу по всем параметрам. А мне норм.

    10/13/15 X: Ты готов любому, кто читает фентези, смотрит смешные картинки и ничего не имеет против геев в лицо сказать, что он не мужик и ответить за это?

    10/14/15 Дмитрий Шишкин: Не согласен по всем трем пунктам. Нет ничего плохого в фентези, просто легкий литературный жанр. Смешные картинки — это норм, если они действительно смешные. Без толерантности плохо. Или давайте вернемся на лет 300 назад и начнем издеваться над инвалидами.

  • Конец феменизма

    cover

    Еще одна годная книженция Никонова о том, как феминизм всех заебал. Ну и про сравнение мужчин с женщинами вообще. Читать стоит.

  • Мудак всегда мудак

    Когда мудак не прав, он начинает апеллировать к законам:

    • По закону я могу слушать громкую музыку до 11 часов.
    • По закону я могу ездить на велике по оживленному тротуару.
    • Это постановление разрешает хранить на лестничной клетке хлам.
    • Согласно это статье я могу парковать корыто перед подъездом.
    • Новый указ какого-то чинуши разрешает попам вести уроки в школах.

    При этом если по закону он прав, то все равно остается мудаком. Точное определение мудака см. у Людвига.

  • Апгрейд обезьяны

    screenshot

    Лучшая книга Никонова. После нее были и про цивилизацию, и про климат, но весь запал, вся страсть – в этой книге. Я вообще делю свою жизнь на две части – до того, как стал читать его, и после.

    Книжка очень хорошо вправляет мозги. Никонов рассматривает темы морали, религии, наркотиков, секса, цивилизации, будущего. Все это идет таким брутальным замесом, подряд. В первый раз мозг взрывает конкретно, потом обломки ложатся на свои места, на этот раз – правильно.

    Некоторые темы Никонов рассматривает слишком упрощенно, о чем пишут критики на обложке. Но книга очень хорошо прочищает мышление, после нее становишься другим человеком. Совершенно по-взрослому начинаешь воспринимать жизнь и те нелегкие вопросы, которые она ставит.

    Обложка полный треш, но у Никонова все такие. Печать, верстка норм.

  • Сначала скажите нет

    cover

    Прозвучит слишком радикально, но тому, кто хочет чего-то добиться, без книжки Кемпа никуда. Это абсолютный маст хев. Кемп учит, как правильно готовиться и вести себя во время переговоров, не испытывать нужду, выслушивать собеседника, держать эмоции под контролем. Кемп рассматривает сложные ситуации в переговорах и успешные выходы из них.

    Ошибочно думать, что секрет книги только в названии. Фраза “скажите нет” – это обобщение сложной системы Кемпа, общий знаменатель, который без числителя не несет никакой пользы. Суть этого “нет” в том, что только отказ дает нам возможность двигаться в переговорах, выстраивая фундамент для следующего вопроса.

    Трудно передать весь опыт, который я вынес из книги. Должна быть на полке однозначно.

  • Введение в Питон. Основы синтаксиса

    Решил перенести уроки с Хексета себе в блог. Есть вероятность, что песочницу, где мои уроки сейчас, закроют, так что путь переезжают сюда.

    Под каждым видосом будет транскрипт (расшифровка слайдов) и код для практического задания. В этом пилотном выпуске нет транскрипта.

  • Как завоевать друзей и оказывать влияние на людей

    cover

    Тот самый случай, когда книгу нужно прочесть всем и каждому. Действительно стоящая вещь. Вы станете лучше общаться с друзьями, коллегами, членами семьи. Советы Карнеги просты, но следовать им трудно из-за человеческой натуры – желания донести до всех свое Я (до которого никому нет дела). Не критиковать, быть снисходительным, уважать оппонента, не перебивать, брать инициативу – эти простые истины хорошо и четко изложены. Истории из практики Карнеги и учеников дополняют советы практикой.

    Книжка небольшого формата и легко читается. Для меня она стала главным удовольствием этим отпуском.

Страница 32 из 46