Когда вы затеваете что то большое, то не можете представлять, чем это все может закончится? Я знаю - обычно это заканчивается тем, что приходится переписывать все с начала. Вы знаете, что я хочу написать? Нет и я тоже не знаю. Почему так, давайте разберемся.
Когда я учился в институте, все преподаватели твердили одну и туже истину, про метод разработки программного обеспечения. Принцип его заключался в иерархическом подходе. Как это работает? Изначально существует конечная цель проекта, потом она разбивается на крупные подзадачи, каждая из них на более мелкие и т.д..
Метод этот называется по научному "Декомпозиция" - приводит он к тому, что на нижнем ярусе так называемой пирамиды образуются элементарные задачи, которые очень просто решить, решая и собирая их в кучу, мы двигаемся вверх по пирамиде пока не достигнем вершины - это и будет конечной целью.
В веб программировании такой подход абсолютно не применим. Почему?
Интернет проекты не имеют конечной цели, они постоянно модернизируются в течении всего срока жизни.
Если уж мы заговорили про пирамиды, давайте представим, что ваш заказчик "фараон", а вы древнеегипетский "зодчий". Вот приходит он и говорит: вот пирамида сможешь? Вы - смогу! Построили, смотрит фараон и говорит: слушай тут такое дело я посмотрел на соседнюю пирамиду, а там балкон! Давай так же, только с колоннами. Да и сфинксов пару туда посади. Вы начинаете говорить про то, что не выдержит фундамент или надо ставить противовес в виде такого же балкона и т.д.. Но фараон то главный! и ставите вы деревянные подпорки под этот балкон чтобы все не рухнуло. На блатном жаргоне программистов "костыли". А потом он туда выходит, да еще и все местное население туда пригласил, чтобы полюбовались и ... Обрастает эта пирамида балконами пока не рухнет.
А все потому, что конечной цели нет. Она, конечно, есть но только в определенный момент времени.
На протяжении трех версий своего "движка" я использовал другой подход. Сетевой.
Суть этого метода заключается в построении не программы, а сети маленьких программ, работающих в комплексе. Те же пирамиды, тоже время. Только на вопрос, где балкон? Ответ - вон он на том холме. А Сфинксы? Сфинксы рядом. И все соединено подземными проходами.
Теперь к сути.
Пишем ядро системы, которое умеет только регистрировать и авторизовать пользователей. Больше ни чего оно не умеет и это хорошо - создали протестировали все работает на 100%, мы получаем от пользователя максимум данных, которые нужны для всего остального. Пользователи главные в любом случае, именно они могут что-то делать на сайте. Затем создаем модуль новости - нужно же мне потом все эти статьи на сайте как-то отображать пока будут писаться другие модули. Что нужно модулю от ядра? Только идентификатор пользователя и его права на создание или редактирования. Это и есть связь. Что дальше? Дальше будет модуль комментариев. Должны же вы писать мне в чем я не прав и советы давать. Что нужно модулю комментариев? От ядра нужен идентификатор пользователя и права на создание. От модуля ему нужно название модуля и идентификатор элемента в данном случае новости. Потом может быть модуль группы! Что ему надо? опять же идентификаторы пользователей и их права. Интернет-магазин! Кому принадлежит (название модуля и идентификатор элемента). Например "группа,112". Кто может добавлять товары - идентификатор пользователя.
Теперь понятно! Каждый модуль должен иметь связь с ядром для получения информации об авторе этого контента и может иметь связь с другими модулями по типу "название модуля, идентификатор элемента".
При таком подходе можно модернизировать модули сколько угодно раз, они абсолютно автономные и способны работать самостоятельно. Дл связи в общую структуру необходимо будет не терять связи.
Почему же четвертая версия? Все дело в структуре данных, которая изначально не была проработана, но об этом в следующей статье.