[Перевод] Framework vs Platform: в чём разница?
Привет, Хабр! Представляю вашему вниманию перевод статьи «Framework Vs. Platform What«s The Difference?» автора G. Harris.
Исповедуюсь: я педант. Несмотря на личные неудачи на этом поприще, я глубоко верю, что использование правильного языка добавляет множество преимуществ. Процитирую афоризм Марка Твена:
Разница между почти правильным словом и правильным словом действительно много значит. Это разница между светлячком (lightning bug) и молнией (lightning).
Ввиду этой разницы я вижу смысл в том, что время от времени меня раздражает недостаток ясности вокруг двух концепций фреймворк и платформа. Какая-нибудь платформа есть у любой компании в мире, которая имеет отношение к разработке. В мире опенсорса полно фреймворков. Но мало кто может определить эти концепции, будучи спрошен. Если я не способен дать чёткие определения базовой терминологии, могу ли я претендовать на полное понимание предмета обсуждения?
Я хотел бы предложить одно из возможных определений по аналогии.
Платформа — это нечто, что можно сравнить с коробкой-конструктором, которая была в комнате у моих детей, когда они были маленькими. Отдельные кубики являются компонентами. На идеальной платформе доступно множество разных комбинаций для сборки компонент, и может быть создан широкий спектр конечных продуктов. Платформы предлагают святой грааль повторного использования ПО: вот почему они так популярны.
Но каковы пререквизиты для построения платформы? Чтобы быть успешной, платформа должна отвечать некоторым обязательным техническим требованиям, и удовлетворить их — задача фреймворка.
- Сначала спросим, откуда взялось определение компонентной структуры? Возвращаясь к сравнению со строительными блоками, выбор доступных к использованию форм ограничен. Какие формы имеют смысл, будет зависеть от руководящих принципов, которые были выбраны с самого начала. Лежащая в основе фреймворка философия будет диктовать выбор возможных компонентных структур. Кстати, «компонент» — это еще одна из тех концепций, которая часто используется, редко продумана и обычно плохо определена. Тем не менее, привлечение простой аналогии сразу проясняет важность хорошо определённой (well-defined) концепции компонента.
- Следующий вопрос, который нужно задать, — это как собирать компоненты. Используется ли технология коннекторов, и как она работает? Конечно, наши компоненты могут быть похожи на деревянные кубики без реальных соединителей между блоками. Но для платформы этого недостаточно. Две возможные альтернативы можно увидеть у Lego ™ и Fischer-Price ™. Обе они позволяют присоединять другие блоки, добавив точки подключения (или порты) к каждому строительному блоку. В идеале именно так должны работать компоненты нашей платформы.
- Последнее ключевое замечание заключается в том, что отдельный строительный блок не знает о внутренней имплементации или свойствах всех остальных строительных блоков. У него есть только точки подключения (порты) и гарантия того, что он может работать вместе с любым другим компонентом, если соединитель (интерфейс) совпадёт. Компоненты являются анонимными, в очень точном смысле этого выражения. Обратите внимание, что это очень похоже на принцип взаимного забвения, выдвинутый Ральфом Вестфалом.
Фреймворк теперь можно определить как набор концепций, библиотек, инструментов и практик, которые обеспечивают:
- Стандартизированную концепцию компонента для использования внутри платформы
- Стандартизированную технологию коннекторов, которая обеспечивает коммуникацию между компонентами в платформе и сохраняет анонимность отдельных компонентов.
Платформа — это набор повторно используемых компонентов, которые были сконструированы в соответствии с принципами и философией платформы.
Возможны и другие определения, но я считаю именно эти определения чрезвычайно полезными.
Прошу заметить, насколько фундаментальной является концепция стандартизации в этом контексте. Задумайтесь на минуту о мире, в котором каждая электрическая вилка была уникальным продуктом ручной работы. Массовое производство электрических устройств никогда не станет индустрией в таком мире. То же самое относится и к платформе. Чтобы они могли играть в команде, все компоненты платформы должны иметь стандартизированную структуру и должны использовать стандартизированные концепции для взаимной коммуникации.
Я объяснил свою точку зрения: платформе требуется фреймворк в качестве основы. Фреймворк обеспечивает парадигмы компонентности и коммуникации. Он обеспечивает стандартизацию, необходимую для создания взаимозаменяемых компонентов. По мере того, как компоненты проектируются, создаются и тестируются, они становятся строительными блоками и вносят свой вклад в платформу. Фреймворк ограничивает степени свободы, которые доступны разработчикам. Он направляет и руководит их усилиями, чтобы достичь той критической степени стандартизации, которая требуется для успеха платформы.
Фреймворк может иметь дополнительные обязанности. В идеале он будет поддерживать концепцию причинно-следственных связей (по-немецки Wirkketten), позволяющую идентифицировать зависимости времени выполнения, потоки данных и потоки управления. Кроме того, он должен содержать (и скрывать) необходимый механизм для работы с параллелизмом. Но это послужит материалом для другой статьи.
