Большая часть программного обеспечения сегодня очень похожа на египетскую пирамиду с миллионами кирпичей, сложенных друг на друга, без структурной целостности, но созданных грубой силой и тысячами рабов.
Алан Кей
Марк устал и голоден. Он решает проверить ближайший торговый автомат. Вставлена монета, выбрана закуска, рельеф, «это было легко».
В параллельной вселенной Марк должен не просто вставить монету, но объявить полный список деталей, которые торговый автомат должен выполнить, чтобы выбросить закуски. Марк должен знать технические детали, крайние случаи. 7 миллиардов человек должны знать все технические детали каждого торгового автомата. Затем в один прекрасный день заменяют один торговый автомат, и все общество разваливается.
Этот причудливый сценарий, хотя и безумный, является прекрасной метафорой для описания современного состояния программного обеспечения. Компоненты, переплетенные с другими компонентами, зная внутренние детали и процедуры, которые им не принадлежат, не могут быть изменены так легко. Обслуживание таких систем - очень сложная и напряженная задача.
В 60-е годы родилась новая перспектива для ее решения. Программа Object Orientation (OO), разработанная Аланом Кеем, родилась в лабораториях Xerox и прошла проверку временем. Сосредоточившись на аппаратных аспектах, правило рассматривало каждый электронный компонент как компьютер. Вдохновленный биологией, где каждая клетка представляет собой машину, теперь процессоры стали машинами, слишком взаимодействующими с другими машинами, такими как доски памяти. Когда эти отдельные машины обмениваются данными между собой, разум может создавать системы, состоящие из нескольких виртуальных машин до миллиардов. С этой новой точки зрения компоненты больше не будут проникать внутрь друг друга. Их можно было свободно заменять, переворачивать и модифицировать.
Однако в этом мире бесчисленных компонентов Алан Кей сожалел об определении объектной ориентации, поскольку это подразумевало, что объекты и компоненты имеют приоритет в системе. Для него обмен сообщениями был главной особенностью. Речь шла о «обмене сообщениями, локальном удержании, защите и сокрытии государства», и ни о чем другом.
Обмен сообщениями в центре приводит к защите и сокрытию состояния, разделяя компоненты. Теперь компоненты - это черные ящики.
Программное обеспечение
Когда его спросили, к каким языкам можно применить объектно-ориентированный объект, Алан Кей ответил: «Smalltalk и Lisp». Лисп, функциональный язык? Зачем кому-то это делать? Потому что объектно-ориентированный подход - это перспектива.
Я повторю еще раз: объектно-ориентированный подход - это перспектива. Это не о языках программирования, классах, функциях, методах, полиморфизме, наследовании, прототипах, изменчивости, неизменности. Это не имеет ничего общего с кодом, экземплярами или тем, как вы ссылаетесь на объекты в памяти. Речь идет о том, что один объект вызывает другой. Такие языки, как C ++ и Java, успешно сузили концепцию до классов и методов. Маркетинг.
На функциональном языке сообщения передаются между компонентами вашей системы для обеспечения логической инкапсуляции. Вы по-прежнему будете стараться не допускать утечки деталей реализации во внешний мир. В Erlang, например, каждый процесс представляет собой функциональную программу, получающую поток сообщений. Вне процесса могут быть всевозможные хаотические явления, бушующая буря, но внутри все спокойно, что позволяет вам сосредоточиться на том, что должен делать этот процесс, и только на этом.
В 1969 году Smalltalk возник как инициатива по применению этих концепций в языке. В нем действительно есть сообщения, защита и скрытие состояния, но это совершенно другое измерение. Впоследствии появились и другие языки. Два самых больших имени сегодня - это C ++ и Java, созданные в 1983 и 1995 годах соответственно. К сожалению, они исказили то, что на самом деле означает объектно-ориентированный объект. Когда его спросили о C ++, Кей ответил: «На самом деле я придумал термин объектно-ориентированный и могу вам сказать, что не имел в виду C ++».
Чтобы иметь возможность использовать объектную ориентацию для управления сложностью системы, нам нужно отвлечься от мысли, что она в первую очередь связана с языками.
В дикой природе: марсоход Curiosity
Curiosity Mars Rover - один из величайших примеров системы, которая построена полностью с учетом объектно-ориентированного подхода, чтобы поддерживать сложность на приемлемом уровне. И угадай что? Написано на C.
Curiosity содержит более 2,5 миллионов строк кода. Состоящие из множества модулей, они используют очередь сообщений, написанную специально для ровера. Когда модулю нужна информация или что-то, что нужно сделать, его сообщения попадают в очередь, которая отправляет их в целевой модуль, который затем выполняет то, что необходимо. Нет мьютексов, нет транзакционной памяти.
Если сообщение является командой, модуль A никогда не ожидает ответа или возвращаемого значения от принимающего модуля B. Если модуль B выходит из строя или переходит в автономный режим, это никогда не влияет на модуль A. Если это сообщение с запросом, то ожидается возвращаемое значение, но состояние изменить нельзя.
Помимо очевидной устойчивости, это отделяет модуль A от модуля B. Сеттеры отсутствуют. При работе с модулем вам не нужно знать, как работает другой модуль. Познавательная нагрузка ниже. Различные команды могут соблюдать договор о том, как интерфейсы проектируются и работают параллельно.
При отладке тоже становится проще. Вы можете применить двоичный поиск, чтобы выяснить, какие модули содержат ошибки. Как только вы найдете проблемные 50%, вы снова выполните поиск.
Изменить систему относительно легко. Из-за того, как вещи разделены, изменение одной части системы не потребует от вас изменения чего-либо еще. Нарушить Закон Деметры практически невозможно. В Erlang, например, процессы развертываются в производственной среде независимо, в то время как другие компоненты продолжают работать.
С другой стороны, НАСА фактически переписало Erlang, в котором есть все эти функции, на C.И, как однажды сказал Джо Армстронг,
Erlang может быть единственным объектно-ориентированным языком.
Перспектива
Мы можем применить эту перспективу сообщений к распределенным системам, микросервисам, текстовым кодовым базам и даже каналам Unix. В коде используйте правильные пространства имен для передачи компонентов, скрывайте свои состояния от других компонентов и начинайте видеть свои методы как представления сообщений.
Все системы будут иметь сопряженные компоненты, определенный уровень сложности и необходимую когнитивную нагрузку. Такова природа, наша задача - управлять ею.
