Предисловие
Хотя меня чаще можно наблюдать в разделе, посвященном ООП, иногда я касаюсь глобальных вопросов программирования в целом и некоторых его аспектов, не связанных с ОО, в частности. Сейчас как раз такой случай, а поговорим мы сегодня о том, чего хотят иметь в авторстве многие начинающие программисты, а именно о движках, двигах, двигателях и подобных, многими не понимаемых терминах. Сразу предупрежу любителей халявы, данная статья не является руководством по написанию "эксклюзивного двига" для вашего сайта, здесь речь пойдет именно о смысловой составляющей этого термина. Начнем.
Заблуждения
Меня много раз спрашивали, почему я не называю свои "движки" "движками"? Ответ прост и сложен одновременно. Дело в том, что термин движка несколько неоднозначен. Если мы возьмем, скажем, игровые движки, позволяющие создавать как игровые карты, так и скрипты к ним, звук и подобные плюшки, то мы опустим из вида множество составляющих этой системы. Двиг многими представляется как некая совокупность кода, который имеет интерфейс взаимодействия и позволяет создавать что то программное. В действительности под данное определение подпадают как языки программирования, так и программные модули, и те и другие могут быть использованы для создания чего либо другого, но, с различной степенью гибкости.
В своей работе я стараюсь строго разграничивать такие понятия, как библиотека, маршрутизатор запросов, хранилище утилит (модулей), визуализатор и так далее. Каждый из этих компонентов выполняет свою функцию и может быть использован как и движок для создания чего то нового, но в отличии от термина "Движок", мы определяем конкретные программные механизмы, дающие нам четкую картину содержимого. Другими словами я придерживаюсь конкретики в выражениях, нежели молодежной тяги к обобщению.
Именно такой подход позволяет мне более полно понять архитектуру этих самых, столь разных, движков.
Совсем немного истории
Начало
С самого начала становления программирования как дисциплины, люди начали стремиться к повторному использованию кода, его накоплению, упрощению понимания программы. Все программисты, и вы не исключения, стремились к написанию собственных "принципиально новых" велосипедов, которые должны были перевернуть привычный мир девелопинга, но большинство этих попыток обычно сводились к накоплению некой библиотеки утилит (функций или классов) и передачи ее в архив после использования любого стороннего продукта. Конечно есть и принципиально новые, но по сравнению с велопарком, это единицы.
Метапрограмминг
С появлением потребности в больших, коммерческих программных продуктах, появилась и потребность в написании таких программ, которые проще сопровождать и модифицировать. Это привело к созданию модулей, отвечающих за автоматизацию многих рутинных операций, что позволило программистам абстрагироваться, то есть отвлечься от низкоуровневой составляющей программирования. Так начали появляться первые программы, создающие программы, то есть очертания любимых всеми движков.
Распространение
Создание метапрограмм, то есть программ, позволяющих создавать прикладные программы, резко ускорило развитие IT индустрии и новые программы появлялись с частотой в несколько штук в день. Многие, как и ожидалось, оставляли желать лучшего, но были и самородки. Дело в том, что такая модель развития отклонила вектор девелопинга от университетов и научных учреждений, к более непринужденному, доступному и простому программированию, это привело к появлению множества не стандартизированных и часто несовместимых программных продуктов.
Унификация
Когда IT мир понял, что для использования одной программы требуется днями искать подходящие для нее компоненты, встал вопрос унификации, то есть стандартизации и приведения разного к общему. Так появлялись первые программные адаптеры, инкапсуляторы и унификаторы, то есть программные модули, позволяющие совмещать несовместимое ПО.
Игровая индустрия
Игры внесли немаловажный вклад в развитие движков, именно на этом рынке зарождались первые механизмы оптимизации и визуализации. Движки в играх строились по тому же принципу, что и корпоративные программные продукты вида b2b (от бизнеса и для бизнеса), но с уклоном на постоянную нехватку ресурсов.
Структура
В качестве примера можно взять практически любой движок, но я использую собственную разработку, так как у меня не будет сомнений в правильности описываемых мною программ. Конечно можно усомниться в полноте материала, ведь мой движок не охватывает такие важные понятия, как скажем рендеринг, звук, обработка видео и т.д., но в качестве простого и понятного примера, он подходит как нельзя лучше.
Как уже говорилось ранее, движок это не конкретный набор программных компонент, более того, нет точного определения этого термина, потому я постараюсь раскрыть это понятие в контексте одного из возможных вариантов.
Много лет опыта
Изучив не мало языков программирования и набив куда больше шишек от собственной криворукости, я, как и ожидалось, пришел к необходимости использования многоуровневой архитектуры программ, а именно расслоения программы с помощью абстракции.
Начал я свою систему (да-да, я не люблю слово движок ;) ) с написания нескольких классов, реализующих некоторые паттерны программирования для PHP. Данные классы (а точнее интерфейсы) позволяли стандартизировать основы архитекутуры будущей системы. Вслед за паттернами были написаны обертки базовых типов данных, добавляющие логику в строки, числа и массивы когда это было нужно. Затем появились классы, скрывающие низкоуровневую логику, такую как работа с сетью, базами данных и файловой системы, от других, более высокоуровневых слоев. Так я создал первый слой системы - слой инструментов. Данный слой делится, как уже было сказано, на слой шаблонов, то есть интерфейсов и классов, упрощающих программирование структуры других классов, и слой классов, включающих низкоуровневые классы для сокрытия логики от других слоев.
Если провести параллель с другими программными системами, данный слой я сравниваю с программными библиотеками, хранящими множество готовых решений простых задач. Важно понимать, что этот слой не должен зависеть ни от одного другого слоя системы, то есть классы этого слоя не должны "знать" о существовании других частей системы. Явно прослеживается программная библиотека, не так ли? Это позволило мне использовать данный слой еще в паре тройке других проектов, но этой другая история.
Вот она, вот она, система моей мечты
Важно понимать, что библиотека классов (или функций) не является частью движка как такового, то есть движки используют библиотеки, но их целью является метапрограмминг, а не аккумулирование программного кода для любых задач, с этой целью лучше справляются языки программирования.
И так библиотека готова, пришло время написать слой служб, то есть классов, отвечающих за работу самой системы. Эти классы активно используют библиотеку и включают такие компоненты, как: конфигуратор системы, локализатор сообщений, кэшер, лог, маршрутизатор, интерфейс взаимодействия с БД и т.д. Именно эту часть я считаю движком, нежели все остальные. Другими словами данный слой создает очертания системы и позволяет настраивать ее достаточно гибко.
Если рассматривать такие системы, как GNU/Linux, то GNU будет являться библиотекой и набором модулей (следующий слой), а Linux тем самым движком, который создает очертания системы и диктует правила работы с ней, но только не нужно синонимировать (есть такое слово? Оо) ядро и движок, это несколько неверно.
Гибкость
С появлением второго слоя, более абстрактного, но и более прикладного, я задался реализацией модулей, то есть программных систем, добавляющих функционал при их подключении. Как программы добавляют функционал ОС, так и слой домена (третий слой системы) добавляет функционал движку. Данный слой не являются частью движка чуть менее чем совсем, это лишь набор готовых решений некоторых прикладных, предметных задач, но без этого слоя теряется необходимость в самом движке (вам ведь не нужен сайт без форума, соц сети и встроенного гугла?!).
Я уже написал более десятка различных модулей и их число растет с каждым днем, но это уже надстройка над системой, нежели развитие самой системы. Модули связаны со слоем служб и используют классы слоя инструментов (библиотеку), то есть они зависят от архитектуры системы, но они взаимозаменяемы и, если постараться, могут быть перенесены на другие движки.
Визуализация
После написания нескольких основных модулей, таких как модуль доступа, регистрации пользователей и системных компонент, я принялся за написания консоли, то есть визуализатора, позволяющего обращаться к модулям через пользовательский интерфейс, а не "вшивая" обращения в код программы. Это было рождение слоя представления, слоя, содержащего экраны, визуализирующие текущее состояние системы в целом.
Данный слой, как и слой домена, включает взаимозаменяемые компоненты и, хоть и зависит от других, но не является частью движка, то есть можно удалить визуализацию вообще, от чего движок не потеряет своей "движучести".
Резюме
Как видите, под понятием "Движок" может скрываться огромное множество различных программных компонент, начиная от библиотек и кончая визуализацией. Подумайте об известных вам wap и web движках с этой точки зрения, и вам удастся лучше понять их структуру и, возможно, улучшить ее.
Охуечумелые ручки
Если вы все таки не поверили моим первым предупреждениям и дочитали статью до самого конца с надеждой найти хоть что то, что поможет вам в написании собственного движка, то вы сделали это не зря! Ура и ах, я немного расскажу о том, с чего можно начать при написании движков, в частности, для web'а.
Чистый лист
В первую очередь нужно понять, что для хорошего дома нужен крепкий фундамент. Скажу сразу, язык PHP настолько сырой, что без множества унифицирующих классов, интерфейсов и методов работать с ним крайне неудобно, особенно когда дело доходит до большого движка. Начните с выбора готовой программной библиотеки или написания собственной. Она обязательно должна охватывать все низкоуровневые операции, в том числе работа с элементарными типами данных, базой данных, процессами, файловой системой, архитектурные решения и так далее. Так же я советую реализовывать эти классы максимально полиморфно, инкапсулированно и гибко, так как их еще предстоит много раз переписать. Предупрежу сразу, многие на этом этапе и останавливаются, так как для продуктивной работы нужен стимул в виде готовой системы, но вы ведь не сдадитесь? Если сомневаетесь, используйте готовую библиотеку (фреймворк на пример, хотя сегодня это понятие смешалось с понятием движка, фу!).
Система
Часто после создания библиотеки (а еще чаще и до этого) пишутся такие модули (именно модули!), как регистрация, разделение доступа и подобное. Многие удивлялись как это я умудрился вывести эту логику на уровень модулей (слой домена) и подключать их в виде отдельных программ, но важно понять, что все, что не относится к архитектуре и низкоуровневым инструментам, является не движком, а модулями. Чтобы было проще, могу посоветовать следующую "лакмусовую бумажку": если некоторый функционал не является используемым всеми возможными модулями, то это модуль, если же это общеиспользуемый функционал, то это движок или библиотека. В моей системе этот принцип прослеживается очень хорошо, с учетом того, что правила построения этой системы содержат больше "букаф" чем эта статься ))) но не будем о грустном.
И так пора писать такие вещи, как служба конфигурации, локализации (хотя это может быть и модуль), Фабрику СУБД и т.д. Эти компоненты описывают очертания будущей системы, хотя я бы посоветовал так же выбрать из того что есть, нежели писать самому, ибо все (конечно не все, но многое) уже давно написано.
Разное
Вот теперь уже можно писать всякие плюшки, которыми грезят многие новички: форумы, чаты, галереи, соц сети и т.д. Это все пишется под созданную (или позаимствованную) ранее систему с использованием созданной (или позаимствованной) ранее библиотеки.
Конец
И вот вы уже (надеюсь) лучше представляете себе, из чего же состоят эти программные монстры и (наверно) хотите заиметь себе парочку, но не спешите, написание движка это работа не на один месяц, порой у меня уходило несколько только на написание пары пакетов, ведь здесь и документация, и тестирование, и реинженеринг, и еще много чего не очень интересного.
Прошу всех, кто зажегся на написания собственного движка после прочтения этой статьи - мотивация это важно, но не надоедайте собственным самолюбием ;)
Удачи в программировании!