Разделить большие классы или загрузить их полностью для вызова одной функции?

Question

Хотелось бы узнать, стоит ли разбить большой класс на разные разделы и использовать их только при необходимости. Если да, то какой будет лучший вариант?

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

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

class User { 
    public $id; 
    public $password; 
    public $password_hash; 
    public $post_count; 

    public function __construct($id) { 
     $this->id = $id; 
    } 
} 

subclass Password of User { 
    public function set($password) { 
     parent::$password = $password; } 
    public function generateHash() { 
     parent::$password_hash = hash("sha256", parent::$password, true); } 
    public function validate($password) { 
     return (hash("sha256", $password, true) === parent::$password_hash); } 
} 

subclass Post of User { 
    public function count() { 
     $db = ConnectionFactory::getFactory()->getConnection(); 
     $sql = $db->prepare("SELECT 1 FROM `Forum_Posts` WHERE `User_ID`=:user"); 
     $sql->execute(array('user' => parent::$id)); 
     parent::$post_count = $sql->rowCount(); 
     return parent::$post_count; 
    } 
} 

$some_bloke = new User(3); 
$bob = new User(4); 
$bob->Password->set('idonthaveaverygoodpassword'); 
$bob->Password->generateHash(); 
$lucy = new User(5); 
echo $lucy->Post->count(); 

Я также думал об использовании нескольких черт, но это не очень подходит, и я боюсь, что это приведет к увеличению использования памяти бесцельно:

class User { 
    use BaseUser; 
} 

class User_Password { 
    use BaseUser; 
    use Password; 
} 

class User_Post { 
    use BaseUser; 
    use Post; 
} 

trait BaseUser { 
    public $id; 
    public $password; 
    public $password_hash; 
    public $post_count; 

    public function __construct($id) { 
     $this->id = $id; 
    }  
} 

trait Password { 
    //stuff 
} 

trait Post { 
    //stuff 
} 

$some_bloke = new User(3); 
$bob = new User_Password(4); 
$bob->setPassword('idonthaveaverygoodpassword'); 
$bob->generatePasswordHash(); 
$lucy = new User(5); 
echo $lucy->countPosts(); 

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

Answer 1

Общая структура, которая может помочь с ООП, независимо от домена, называется SOLID. В общем случае он может применяться к любому домену, пытаясь выполнить каждый принцип, который он определяет. Это, как говорится, SOLID это только основа, и код может выполнять твердые принципы, в то же время Бейна трудно работать :(Постараюсь ответить довольно общее применение его в домене:

Single Ответственность У каждого класса есть только одна причина для изменения. Если изменится алгоритм хеширования или соль, который будет изолирован от одного места? Да. Что, если требования изменились, а организация не хочет отслеживать необработанный пароль в памяти? Нет. И пользователю, и паролю необходимо изменить.

Открыть/закрыть Как мы будем создавать новые типы сообщений s, Пользователи или пароли? Что делать, если бизнес хотел бы добавить не прошедшего проверку пользователя, которому не нужен пароль. Могла ли она быть смоделирована в системе без изменения модели пользователя? Что делать, если у неавторизованных пользователей всегда было 0 сообщений?

Liskov Замена Указывает, что все объекты должны быть заменены экземплярами их подтипов. Это часто проверяется только после создания кода, который использует ваши объекты домена. В этом случае:

$some_bloke = new User(3); 
$bob = new User(4); 
$bob->Password->set('idonthaveaverygoodpassword'); 
$bob->Password->generateHash(); 
$lucy = new User(5); 
echo $lucy->Post->count(); 

Если $bob были экземпляром Post не сможет быть реализован с использованием Password, который является подклассом User, то же самое для $lucy быть экземпляром Password вместо User.

Интерфейс сегрегация

Dependency Inversion

---

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

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