Использование абстрактных классов и статических членов для лучшего управления функциональностью - PullRequest
3 голосов
/ 09 декабря 2010

Чтобы лучше организовать мой код в PHP-проекте ( простая CMS), я рассматриваю возможность перемещения большинства моих системных функций в абстрактный класс в качестве статических членов.Помимо организационной и синтаксической выгоды от этого, единственной другой причиной было бы сохранение ссылок на объекты источника данных и т. Д., А также статических элементов.

Правила нарушаются при необходимости, но я хочуукрепить мое понимание лучших (читай best ) шаблонов и практик.

Я полагаю, что этот вопрос является открытым, но мне было интересно, есть ли у кого-нибудь предложения или, возможно, можно было бы предложить некоторые материалы для чтенияпоэтому я мог изучить свои варианты и то, что можно было бы считать «лучшими практиками».

Примером этого в моем коде могут быть функции для управления разрешениями.Для любого данного запроса может потребоваться проверка разрешений, чтобы гарантировать, что запрашивающий пользователь имеет достаточные привилегии для операции.Таким образом, такие функции, как getAllPermissions(), getGroupPermissions(), addGroupPermissions() и т. Д., Плавают вокруг.Должны ли они быть инкапсулированы в класс PermissionsManager, необходимый для создания экземпляра, и если да, то где мне остановиться?Я на правильном пути, перемещая их в псевдоглобальное пространство в абстрактном классе как статические методы?Должен ли я просто оставить декларации в глобальном масштабе?Где заканчиваются соответствующие обязанности класса и начинаются захваты «божьего класса»?Какие цветные носки я должен носить?

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

Ответы [ 2 ]

3 голосов
/ 09 декабря 2010

предложить некоторые материалы для чтения

Взгляните на SOLID и GRASP и мой ответ: Шаблоны проектирования Php

Должны ли они быть инкапсулированы в классе PermissionsManager

Да. Если эти функции связаны, сгруппируйте их. Также ознакомьтесь с этой статьей Википедии о списках управления доступом на основе ролей и взгляните на различные вопросы об ACL в PHP на StackOverflow.

Я на правильном пути, перемещая их в псевдоглобальное пространство в абстрактном классе как статические методы?

Нет, , по возможности, следует избегать статического. Статика ведет к тесной связи и вводит зависимости от глобальной области действия, что приводит к уменьшению объема поддерживаемых приложений, что приводит к более длительному времени доставки (например, исправления ошибок и новые функции) что приводит к более высокой общей стоимости и меньшему возврату инвестиций.

Должен ли я просто оставить объявления в глобальной области видимости?

Если вы внесете изменения в свое заявление, вы сможете объяснить это преимущество. Если вы думаете, что ваше приложение может извлечь выгоду из рефакторинга этого кода, то рефакторинг его. Вы должны остановиться, когда нет возврата инвестиций.

Где заканчиваются соответствующие обязанности класса и начинаются захваты «божьего класса»?

Поскольку вы должны придерживаться принципа единой ответственности , любая ответственность, кроме одной, - это кодовый запах (хотя иногда может иметь смысл иметь более одного). Я нашел это описание GodClass легким для понимания.

Какого цвета носки я должен носить?

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

Я не хочу больше бездействовать на моделировании

Некоторые мысли, прежде чем начать, это хорошо. Понимание проблемы и области, которую вы хотите решить, необходимо для принятия решений. Но вы должны начать с решения проблемы в конце концов. Только рабочий код (даже плохо разработанный) дает бизнес-ценность. Нетронутые предварительные проекты в любом случае не выживут в реальности проекта.

1 голос
/ 09 декабря 2010

Как общий совет, вам следует избегать статических функций по крайней мере любой ценой, если вы следуете по маршруту ООП.В ООП ваш код очень похож на естественный язык, а вызовы функций следуют фразовой структуре «субъект-глагол-объект»: «кто-то что-то делает (с чем-то другим)».«Несвязанные» (глобальные и статические) вызовы похожи на фразу без субъекта, «это делается с чем-то», что, конечно, вызывает некоторые неотложные вопросы - кто является участником этого действия?кто несет ответственность за последствия?как мы можем заменить это действие чем-то другим, для целей тестирования?и т. д.

Эта метафора естественного языка чрезвычайно полезна, когда вы сталкиваетесь с проблемами проектирования.Запишите свою проблему в простых фразах.Подчеркните предметы, глаголы и предметы.Перепишите текст на языке программирования, следуя шаблону $subject->verb($object) - и вуаля, все готово.

Вернемся к вашему примеру с разрешениями: вы спрашиваете, есть ли у пользователя $ u разрешение $ p длясущность $ е.На естественном языке вы можете выразить это тремя различными способами, в зависимости от того, что вам нравится быть предметом:

  • "Может ли Джо читать foo.txt?"(subject = user)
  • "Может ли Джо читать foo.txt?"(subject = entity)
  • и даже "Предоставлено ли Джо разрешение на чтение для foo.txt?"(субъект = разрешение)

Все три способа звучат хорошо и могут быть немедленно переведены в код OOP-php:

if ($user->can_read($file)) ...
if ($file->is_readable_by($user)) ...
if ($read_permission->for_entity($file)->is_granted_to($user)) ...

Нет необходимости в статических функциях.

...