Лучший способ организовать иерархию классов PHP - PullRequest
Новая
       17

Лучший способ организовать иерархию классов PHP

3 голосов
/ 21 октября 2008

У меня есть довольно примитивная среда, которую я использовал для большинства своих проектов, но мне пришла в голову общая проблема дизайна, которую я пока не смог решить. Для данного приложения, я должен отделить структуру класса приложения от структуры фреймворка, или сборка поверх фреймворка не такая уж плохая вещь?

Например, скажем, у меня была платформа с базовым классом Controller и она была расширена для данной части моего приложения. Какое расположение имеет наибольшее значение и почему?

Структура класса A:

  • Интуитивно понятный, легко найти исходные файлы при отладке.
  • Имена файлов / структура каталогов отражает иерархию классов. 
- Framework_Control                 "Framework\Control.php"
   - Framework_Control_Index        "Framework\Control\Index.php"
   - Framework_Control_Home         "Framework\Control\Home.php"
   - Framework_Control_Contact      "Framework\Control\Contact.php"
   - Framework_Control_About        "Framework\Control\About.php"

Структура класса B:

  • Сохраняет модульную структуру и легко заменяет / обновляет.
  • Добавляет некоторую сложность структуре каталогов, именование каталогов / файлов больше не следует за иерархией классов. 
- Framework_Control                 "Framework\Control.php"
   - Application_Control_Index      "Application\Control\Index.php"
   - Application_Control_Home       "Application\Control\Home.php"
   - Application_Control_Contact    "Application\Control\Contact.php"
   - Application_Control_About      "Application\Control\About.php"

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

Ответы [ 2 ]

2 голосов
/ 21 октября 2008

Я бы посоветовал вам просматривать ваш исходный код в двух разных категориях: внешние зависимости или код, который используется на нескольких сайтах и ​​не является родным для какого-либо одного, а также родные зависимости или код, который является родным для определенного вами сайта. работает над.

Похоже, Framework / Control.php является частью большей внешней зависимости и должен управляться как таковой, в то время как все файлы Application / Control являются родными для конкретного веб-сайта.

Использование этого различия в нашей структуре кода значительно упростило повторное использование нашей внутренней структуры между несколькими сайтами.

В качестве заключительной мысли вы могли бы рассмотреть, что делают основные платформы, такие как Zend Framework, Symfony и другие. Несмотря на то, что вся инфраструктура может быть больше, чем вы хотите, структура платформ может дать много общего с общими, хорошими практиками, которые используются разработчиками PHP повсюду.

1 голос
/ 21 октября 2008

На самом деле все сводится к тому, что вы собираетесь делать при обновлении Framework \ Control.php в Application XYZ. Собираетесь ли вы вернуться в Application ABC и внести те же изменения? Что если это критическая ошибка?

Для удобства сопровождения всех ваших проектов я бы выбрал второй вариант.

...