Шаблон дизайна для пользователей

Question

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

• Создание пользователя
• Изменения для пользователя
• Удаление пользователя
• Чтение пользовательских данных

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

У нас также будет этот класс users, который будет управлять группами пользователей.

Я использовал следующие 2 варианта (упрощенно):

Разного класса для различного назначения

- class UserMaker($username, $password, $email);
    function giveBirth(); // create the user

- class UserManager($id);
    function edit($field, $value); // edit a specific user field
    function save(); // save all the edits with a single query
    function setTrusted(); // set that user as trusted
    function setAdmin(); // set that user as admin
    function setBanned(); // ban the specific user

- class UserReader($id);
    function get($field); // Get the value of a single field
    function getAll(); // Get all fields from that user as associative array
    function isAdmin(); // self explanation
    function isRegistered(); // self explanation
    function isBanned(); // self explanation

Одноместный класс

- class User($id);
    function static giveBirth($username, $password, $email); // create the user, notice this is static

    function edit($field, $value); // edit a specific user field
    function save(); // save all the edits with a single query

    function setTrusted(); // set that user as trusted
    function setAdmin(); // set that user as admin
    function setBanned(); // ban the specific user

    function get($field); // Get the value of a single field
    function getAll(); // Get all fields from that user as associative array

    function isAdmin(); // self explanation
    function isRegistered(); // self explanation
    function isBanned(); // self explanation

По сути, поскольку единственный класс, который не принимает $ id в качестве аргумента для __construct(), это UserMaker, мы просто устанавливаем функцию giveBirth() как статическую, чтобы мы могли создать пользователя.

Каков наилучший способ создать этот шаблон? У вас есть третий вариант, который вы чувствуете себя лучше, чем эти?

Answer 1

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

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

class UserFactory() 
    getModel();
    getUser($id, $model = null);
    getACL($user);

class UserModel ()
    edit($id = 0);
    load($id = 0);
    reload($id = 0);
    save($id = 0);

class User ($data)
    getAll();
    getField($field);

class UserACL (User $user)
    isTrustedUser();
    isAdminUser();
    isBannedUser();

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

Answer 2

Я не знаю, как именно вы организовали / представили вещи в вашей системе, хотя из подходов, которые я использовал, я обнаружил, что наиболее эффективный способ обработки вещей - это представление объектов как сервисов, например: Сколько раз в вашем программном обеспечении будет вызываться метод giveBirth? один раз, еще два? почему больше?

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

1. Создать интерфейс (или интерфейсы) с заголовками методов.
2. Создайте SINGLETON, который реализует интерфейс (все интерфейсы). Это потому, что я предполагаю, что у вас никогда не будет более одного экземпляра пользователя во время одного запроса (факт, который также доступен для сеанса).

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

UserSingleton::init($_SESSION["id"]); 

после того, как процесс запроса инициализирует объект пользователя, вы можете использовать это:

$user =  UserSingleton::getInstance(); // will return the instance of singleton

$user->setBanned();// or whatever you need to call;

Obs: Вы можете избежать метода init, создав getInstanceMethod следующим образом:

 public function getInstance(){
       if(!isset(self::$instance) {
           self::$instance = new UserSingleton($_SESSION["user_id"]) ;
       }
       return self::$instance;
 }

Обратите внимание, что это не должно обрабатывать такие вещи, как взаимодействие с базой данных, это должно получать / отправлять данные в / из базы данных через внешние вещи. Это помощник, а не бизнес-модель / объект. Это еще одна проблема.