Принцип программирования DRY.
Когда вы начнете разрабатывать сайт или любой другой крупный проект, вы скорее всего встретитесь с проблемой реализации логики и его сложностью. Это довольно частое явление и как вы уже догадались, у которого есть решение. Ее идея состоит в том, чтобы разделить сложную задачу на независимые модули, иначе подзадачи, каждая из которых будет отвечать за определенный алгоритм или логику в проекте.
Как это работает?
К примеру, в любом простом проекте по WEB-разработке, мы как правило, соединяем бэкенд часть с фронтендом, а далее с базой данных. Абсолютно на любой странице, требующей связь с базой данных есть компонент, отвечающий за подключение к БД. Этот компонент делится еще на другие компоненты, каждый из которых отвечает за подключение, завершение сессии и т.п. Так вот, именно разделяя систему на такие самостоятельные и отличительные друг от друга компоненты вы начинаете понимать, что каждая из них может самостоятельно отвечать за определенную логику действий.
Важно помнить, что даже после разделения системы на подчасти, все отдельные части должны иметь одно представление.
Когда мы соединяем БД к бэкенд части, то мы получаем код, который по порядку: подключает бэкенд к базе данных, получает нужные данные, отключает соединение по окончанию сессии. Любая из этих действий, повторяемая на каждой странице, является информацией, которая описывает то, как мы делаем то или иное действие, в нашем случае, к примеру, подключение к БД. Перед тем как описывать действие, мы привязываем ее к определенной переменной. Теперь переменная, указывающая на информацию о соединении с БД будет являться представителем этой информации, а переменные, мы знаем, можно использовать в любой части кода, системы и логики при необходимости. И если вдруг возникнет необходимость переписать схему соединения с базой данных, нам достаточно будет изменить/переписать логику информации о подключении, но не их представление в коде.
В идеале это так и работает, часто повторяемую логику действий мы записываем в отдельную информацию, которой мы можем воспользоваться через создание переменной или метода в разных частях проекта, тем самым как бы “инкапсулирует” данные о подключении. Инкапсуляция, заметим, является одной из самых основных принципов Объектно Ориентированного Программирования (ООП). Вы используете метод подключения к базе данных в какой-то части кода, но не видите всей той картины, как именно этот процесс проворачивается внутри системы, потому что вы сейчас работаете с представлением, но не информацией о ней.
Как перестать повторяться?
Если подумать, то можно каждую часть кода разделить на логики и работать только с их представлениями, но не тут-то было. Ведь важнее всего не переборщить с упрощением вашего кода, потому что можно легко запутаться в будущем. Используя принцип DRY в логике проекта, вы должны четко построить архитектуру работы проекта: что с чем связано и как именно, какая логика следует за этой логикой, как именно можно реализовать эту информацию в отдельный метод и т.д.
Чтобы не ошибиться и не забыть важные моменты основной идеи проекта, можно придерживаться самых простых рекомендаций, следуя которым вы и не заметите как будет легко выстраивать логику таким образом, чтобы код не повторялся:
✔ Визуализируйте. Часто можно услышать то, что люди предпочитают рисовать схемы во время планирования или запоминания какой-либо информации. Никто бы не продолжил делать это, если бы это не было действительно эффективным. Рисуя графическую схему программной системы вы сможете легче понять то, на какие компоненты его можно будет разделить так, чтобы суть оставалась одной, а компоненты были связаны логически правильно.
✔ Что и для чего. Разделяя систему на компоненты нужно обязательно ответить себе на просто вопрос о том, почему вы вынесли этот кусочек кода как отдельный и независимый компонент. В запоминании этой логики вам помогут UML диаграммы.
✔ Доступ. Раз мы уже затронули тему об инкапсуляции данных, то нужно сразу отметить то, что перед тем как начать отделять кусочек кода в отдельный компонент так, чтобы им могли пользоваться и на других страницах системы, мы обязательно должны продумать то, какая информация о компоненте может быть доступна внутри другой страницы, а какая нет. В помощь вам слова, как : private и public аксессоры.
✔ Связи. Разделяя код на независимые части/компоненты, все же важно помнить о том, что они независимы друг от друга, но связаны между собой, причем связь между ними должна быть максимально слабой, иначе смысла в выводе этих компонентов как отдельную логику не будет.
Заключение о том,
как не нужно делать для того, чтобы не повторять свой код.
✔ Старайтесь успевать по дедлайнам. Это почти самая главная причина, по которой многие программисты склонны к тому, чтобы просто копировать и вставлять рабочий код где попало. Они просто не успевают по дедлайнам и у них недостаточно времени для того, чтобы вникнуть в логику рабочего процесса в системе.
✔ Будьте внимательны. Если вы повторяете одно и то же действие в разных частях кода/программы - это знак того, что этот кусочек кода заслуживает быть отдельным компонентом.
Создание сайтов в Алматы.
