Простые решения, простая жизнь!Привет. Сегодня затронем очень важную и щекотливую для всех разработчиков тему – о том, как же писать те самые простые приложения и как вообще отличить простое от сложного. Использовать ли ООП, или процедурный подход. Как же понятный код отличается от непонятного. Мы также будем все разбирать с точки зрения практики, а не голой теории. Постараемся выносить оценки максимально объективно. Затронем модель вьювер контроллер и базовые принципы программирования в разных средах. Ниже я буду приводить, казалось бы, основные аксиомы, а после мы соберем их них базовые правила.
Некоторые обобщения касаются только WEB, по этому читатель, занимающийся созданием программ в других областях может частично не согласится с ними.
Основное правило простого кода – если можно решить задачу проще – нужно делать проще. Если для решения чего-либо – у вас есть выбор – использовать 1000 строк или 20 строк кода, и результат задачи при этом не изменится – берите 2й вариант. Согласны?
Если что-то можно разделить логически – это нужно разделить. Давайте не будем смешивать все в один котел. Максимально разделяем логически обособленные операции.
WEB. Чем меньше файлов и строк кода будет задействовано – тем быстрее и надежнее сработает программа.
Отсюда следует, что любой скрипт логически можно разбить на 3 блока – обработка входных данных, модуль для расчетов, вывод данных. Логически различаются, поскольку задействуют разные части.
Первая – ловит входные данные, понимает, находит модуль, который будет заниматься логической обработкой
Вторая – логически обрабатывает все, что относилось к данному модулю, рассчитывает выходные данные
Третья – Отображение - расставляет выходные данные в удобный для чтения вид, рисует разные красивости и формочки. Другими словами – шаблонизатор.
Так появляется архитектура MVC. Минимум вложенных файлов (3 штуки). Максимум разграничений. Изменение одного модуля не приведет к падению всего, если в нем будет ошибка. Блок отображения данных может быть легко изменен верстальщиком, не дергая разработчиков. Все максимально просто, максимально разделено.
Также в расчетах могут понадобиться посторонние логические части, которые одинаковы для многих отдельных функций. Назовем их классами. Классы хороши сами по себе. Каждый класс предназначен для работы с отдельной областью, позволяет удобно из любого места совершить множество одинаковых логических операций.
К примеру – класс для работы с почтой, базой данных, аськой, графикой, для экспорта в эксель… да мало ли отдельных кусков, которые могут отдельно понадобится в разработке
Больше ничего не нужно. Делаем проще. В итоге получается быстрее и экономичнее.
Какие есть альтернативы? ООП?
В программировании существует такое понятие, как ООП. Или объектный подход. Возможности он открывает очень большие. И по существу должен быть очень простым.
Давайте расскажу Вам про ООП на простом языке
Вот у нас есть животное. Мы описали это животное, оно может подавать голос, может ходить. Теперь мы можем создать, сколько хотим животных. И каждое из них будет подавать голос и ходить.
После этого мы можем рассказать компьютеру о собаке. И сказать что собака – является животным, а значит, оно умеет ходить и подавать голос. Мы также можем сказать, что собака подает голос «Гав-Гав». По аналогии мы можем создать класс кошек с указанием подачи голоса через «Мяу».
Теперь мы можем создать, сколько хотим кошек и собак. Программа будет знать, что все они умеют бегать и подавать голос. При том каждый вид будет подавать голос по своему, нам лишь нужно скомандовать.
Возможности встроить один объект внутрь другого, множество раз наследовать все свойства и всячески их связывать между собой при малейшей надобности заставляет людей усложнять модель. Получается завязанный клубок, дергание, за каждую нитку которого может привести к зажиму в другом месте системы. Вы пытаетесь добавить еще один кубик сверху, но за счет завала в основе – вся конструкция может упасть. Отсюда пошло выражение «работает – не трогай». И правильно, кому охота возиться с системой, которая может даже не подняться после падения… Чревато головными болями.
Такое событие приводит к замусориванию само по себе. Ведь исправить неправильный элемент в самом основном классе нельзя, он точно отразится в 1000 других местах, где надо будет тоже придумывать решение. По этому проще создать новый метод, своеобразный костыль, для затыкания сиюминутной дырки.
К чему приводит такая ситуация в дальнейшем? В огромные затраты. Теперь нам нужно содержать отдел тестировщиков, которые будут тестировать приложение после каждого исправления на предмет – не отвалилось ли в другом месте при исправлении в первом. Теперь разработка занимает больше времени, т.к. разработчику нужно для каждого своего модуля в каждый момент писать юнит тесты. А также подробно описывать документацию по каждому классу.
Не создавайте классы, в которых всего один метод. Это затрудняем код, пользуйтесь функциями.
Где нужны классы?
Классы очень хорошо подходят для обобщения множества функций, относящихся к одному действию. Это также может использоваться в WEB. Выше я об этом уже писал.
К примеру, класс для работы с почтой:
Нам нужно сформировать письмо, вложить файл и отправить 3 адресатам через SMTPпротокол. В классе уже прописаны все эти мелочные методы. Нам лишь нужно последовательно создать все эти команды. Мы можем обойтись и без класса, но тогда нужно каждый раз вспоминать о той последовательности отправки команд серверу через сокеты. Зачем делать это каждый раз, когда они все время одинаковы.
Также классы очень хорошо подходят для создания множества похожих объектов одновременно. Это очень удобно, если вы создаете стационарные игрушки (приложения). Объявили класс человека, расписали как он ходит, как атакует. Далее – можно унаследовать разные классы врагов. Те, у кого есть пистолет – могут стрелять, те, у кого скакалка – могут прыгать высоко. Далее – каждому добавляем параметр команда и ИИ. Теперь – мы можем легко маневрировать в данной песочнице, создавать любые баталии, играть за любого типа соперника, хоть вдвоем, хоть втроем. Все легко управляется и настраивается.
Только! Это не работает в WEB. Потому что специфика httpпротокола не позволяет держать соединения и выводит результат в зависимости от запроса. Объявлять все множество объектов каждый раз при обращении к странице очень ресурсоемко. Обычно растянутые во времени операции происходят при множественном обращении через AJAX, или через определенное время.
WEB– преимущественно отображает данные. Для расчета логики никто не запрещает использовать классы, только следите за прозрачностью, это очень важно
Итак:
Держите код простым, прозрачным. Делайте, как можно проще! И люди к Вам потянутся