Зачем использовать более одного или нескольких файлов для компьютерного приложения?
Я начал делать свой собственный очень маленький фреймворк php, затем изучил (очень) основы фреймворка Symfony. Небольшой веб-сайт Symfony содержал более 11000 файлов в 1000 каталогах. Я вернулся к своей собственной структуре и все больше сопротивляюсь созданию новых файлов.
Я занимаюсь созданием DRY, кода MVC, что означает, что мне действительно нужен один файл для приложения и один файл для кода, который используется несколькими приложениями. По сути, мне нужно n + 1 файлов, где n — количество созданных мной приложений. Это не включает ресурсы, такие как файлы изображений. Я что-то здесь упускаю (прежде чем потратить слишком много времени на такой подход)? Каковы преимущества распространения кода по многим файлам? Является ли один большой файл хуже, чем многие маленькие файлы, которые в сумме составляют общий объем кода?
Решение
Краткий ответ: разделение проблем.
Предположим, у вас есть два приложения, одно из которых отображает информацию о погоде, а другое — стандартные обновления. По-видимому, они не имеют ничего общего друг с другом, поэтому вы помещаете их в отдельные файлы. В конце концов, вы действительно не хотите, чтобы между вашими биржевыми кодами обновлялся код погоды.
Некоторым из этого кода можно поделиться. Вы можете поместить этот код в общую библиотеку. Все идет нормально.
Но что произойдет, если вы обнаружите, что какой-то код из погодного приложения действительно может быть использован для стоковых обновлений? Например, код для выполнения запроса клиента веб-службы. Вам придется удалить этот код из одного файла погоды и поместить его в библиотеку. И эта библиотека со временем станет очень большой, с функциями, которые могут не понадобиться новым приложениям.
Если вы храните все в одном файле, они неизбежно станут неразделимыми шарами пряжи, с дублированным кодом и другими подобными тонкостями. Их будет сложно выполнить модульное тестирование, и вы забудете, где находится код и что он делает. У вас будет дублированный код, а ошибка, исправленная в одном месте, остается нерешенной в другом.
Вот почему рекомендуется организовывать функциональность таким образом, чтобы сходные функции находились вместе, чтобы webclient.php имеет дело с клиентами веб-службы, а не теряется где-то в weather.php,
Другие решения
TL; DR
Ваш код читабельности и ремонтопригодности. Для этого вам следует нанять
- Разделение проблем,
- Низкая связь,
- Высокая сплоченность
Объяснение
Чтобы немного уточнить ответ SeverityOne. Не все идет с принципами разделения интересов, хотя это, несомненно, одна из самых важных вещей в современном программировании (черт возьми, в программировании вообще).
Вы можете написать свой код, как вам нравится. Я знаю парня, который написал свой код, однако ему понравилось. Но если вы работаете в команде или ваш код должен обслуживаться кем-то другим, подготовьтесь к тому, чтобы ваше имя стало синонимом «тупая утка» и «да-хо». Когда я начал поддерживать код этого парня после него, его имя стало синонимом «тупая утка» и «да-хо». Причина? Не читаемый код без мысли в нем. Там, где задача могла занять час, потребовалось шесть, чтобы, наконец, понять, что имел в виду этот тупой утка, с его переменными утки да-хо. Слава богу, тупая утка больше не работает с нами, и мы выбросили «код», который он создал, и начали переписывать с нуля. Видишь, как мои эмоции выплескиваются? Это потому, что эта тупая утка думала так, как ты: «ах, зачем идти на удобочитаемость и ремонтопригодность, когда я могу получить бутерброд с кухни компании!»
Чтобы ваши коллеги хотели работать с вами, вам нужно подумать о том, как правильно поддерживать свой код. Вы думаете о разделение интересов — SeverityOne уже объяснил вещь.
Вы также должны поддерживать низкая связь, то есть степень, в которой разные классы зависят друг от друга. Идея слабой связи заключается в том, что ваши классы (или модули) должны быть настолько независимыми, насколько это возможно, и в лучшем случае никогда не должны «знать» друг о друге.
И, наконец, имейте в виду, высокая сплоченность. Сплоченность относится к степени, в которой элементы класса принадлежат друг другу. Идея заключается в том, что связанный код должен быть близко друг к другу и связывать весь связанный код как можно ближе.
Пример
Вы создаете блог. Просто подумайте о типичном примере блога. Плохой подход состоит в том, чтобы создать 2 метода для составления списка ваших постов и отображения одного поста, все в одном файле, выполнения запросов в одном и том же файле, записи html и css в одном и том же файле, что бы ни приходило в голову. Почему это плохо? Что если Бобу или Алисе нужно добавить новый столбец в базу данных? В скольких местах они должны редактировать SELECT запрос? Какую часть HTML они должны редактировать впоследствии? Можете ли вы угадать, сколько часов это займет? 5? 17? 42?
Хорошим подходом было бы разделить каждое сообщение в блоге на конкретную сущность, связанную с ORM (или чем-то еще, но мой личный фаворит — Hibernate (Java) / Doctrine (PHP)). Затем, при правильном использовании с Symfony, вы создаете 2 коротких метода для выбора и отображения информации о листинге или записи блога. Вы поддерживаете HTML / CSS в Twig. Что происходит, когда Бобу или Алисе нужно добавить столбец в базу данных? Файл миграции с коротким UPDATE запрос, одна строка кода в вашей сущности, пара строк кода в Twig. Быстро, чисто, ремонтопригодны. Время? Менее одного часа.
detector