Как избежать хаоса SRP?

Это относится ко всем типам библиотек. Не только СРП.

Организация классов / функций может быть головной болью, но на самом деле есть всего несколько вещей, которые вам нужно иметь в виду.

1. План.
2. Определите и сохраните правильное соглашение об именах для файлов, классов, папок, методов / функций и переменных.
3. Разбивайте свои классы в пространства имен или, по крайней мере, в подпапки основными группами мышц системы.
4. Документ: внутренне (хорошие комментарии, заголовки файлов и списки общедоступных методов) и внешне (wiki, readmes, excel, something)

К 2 я имею в виду: /library/muscleGroup/useType_nameOfClass.php для файлов / папок, где useType – это что-то вроде «заводского» «абстрактного» «data / dto» или любых других шаблонов, которые вы используете. Затем в каждом файле класс должен быть таким же, как nameOfClass, и каждое имя метода должно строго следовать шаблону. [Action][on what][with what conditions] и сохранить список действий и «на что» и придерживаться их РЕЛИГИОЗНО.

Сделайте это, и вы не можете дублировать функциональность, так как вы можете легко найти нужные классы и методы для вещей, которые вы хотите. Поскольку у них есть логические имена, такие как Get_User_ById и Get_Transactions_ByNewest или Combine_Ingredients_FromRecipes .

Этот последний может содержать комментарий выше:

 // Combines many recipes into one ingredient list // $recipes = an array of recipe objects // returns an array of ingredient objects with their correct quantities 

Список примеров действий: (должен быть довольно общим и применяться к любому приложению)

• Получить
• Задавать
• Удалить
• Переехать
• сливаться
• скомбинировать

Список образцов «О том, что»: (должен быть конкретным приложением)

• пользователь
• Ингредиент
• Рецепт
• измерение
• разрешение
• марка
• Объявление

Зависит от проекта, но если это было что-то, что имеет много CRUD без значительных бизнес-правил, я бы хотел создать простую структуру с файлами скриптов для поддержки этого решения. Я делал это в прошлом, и он очень быстрый, но медленно меняющийся. Обычно Эрик Эванс называется анти-шаблоном Smart UI:

«Поместите всю бизнес-логику в пользовательский интерфейс, отбросьте приложение на небольшие функции и реализуйте их как отдельные пользовательские интерфейсы, внедряя в них бизнес-правила. Используйте реляционную базу данных как общий репозиторий данных. Используйте наиболее автоматизированное здание пользовательского интерфейса и инструменты визуального программирования [Evans с.77]. "

Если вы делаете что-то с большим количеством реальных бизнес-правил и имеете больше времени, или вы ожидаете, что он будет иметь долгую жизнь:

1. Выясните задачи системы и попытайтесь реализовать эти задачи как команды более высокого уровня.
2. Попросите команды более высокого уровня манипулировать базовыми классами низкого уровня и вызываться из ui. Я использую Zend Framework, и у меня есть контроллеры, которые называют эти команды высокого уровня, но в большинстве случаев это слишком много. У меня эти классы хранятся в папке приложения, разделенной на модуль (учет, электронная почта и т. Д.).
3. Классы нижнего уровня хранятся в папке «Домен», которая также разделяется на те же модули, что и папка «Приложение». Классы Domain представляют объекты, над которыми работает (Email, ClassCredit). Они небольшие, и только выполняют задачи, которые имеют смысл для этой концепции.

Что касается ресурсов, которые помогут вам в дальнейшем, ознакомьтесь с « Чистым кодом » Боба Мартина и Domain-Driven Design (не может опубликовать другую ссылку) Эриком Эвансом. Обе книги блестящие и предлагают тактические и стратегические шаги, соответственно, для решения этого хаоса.

Структура папок

Zend Framework организует свои классы по функциональности и называет их как таковые. Например, класс Zend_Controller_Action_Helper_AjaxContext находится в /library/Zend/Controller/Action/Helper/AjaxContext.php .

Это служит двум целям: организация папок и логическое разделение функциональности. Вы всегда сталкиваетесь с проблемой «запоминания того, что вы строите», но, применяя SRP и размещая функциональность, где она логически «самая правильная», вы можете сбить с толку.

IDE

При работе с множеством классов необходима интеллектуальная среда IDE. Ярлыки, которые позволяют разработчику быстро находить классы, имена файлов и методы в любом месте проекта, имеют дело с тысячами классов, почти тривиальными.

Используя тот же пример, что и выше, нужно уметь находить класс различными способами:

• Поиск имени класса. В EclipsePDT это так же просто, как ctrl+shift+T для поиска классов (типов). (примечание: я честно не знаю, является ли это особенностью затмения или добавлением плагинов PDT).
• Аналогично, вы можете искать по имени файла с помощью ctrl+shift+R (resource).
• Или методом внутри класса ctrl+shift+m