Dealing with large classes, how to break them down? - php

Question

Looking more into OOP and classes, I have an extremely large user class which is becoming increasingly large to manage. The total code is in excess of 950 lines and completely dismisses the Single Responsibility principle.
A few ways i thought to make this smaller is to create completely seperate classes and transfer the data in on the construction of the new class. For example:
index.php
$user = new user('username');
$userOptions = new userOptions($user);
or
$user = new user;
$userOptions = new userOptions;
$userOptions->setData(
$user->getData([
'username'=>'genericuser'
]),
);
However this seems un-natural and isn't as nice as i would expect properly formatted code to be.
Another way i thought of is to extend the base class into another one. For example:
index.php
$userOptions = new userOptions('username');
classes/useroptions.php
class userOptions extends User {
//a small section of what would be a big user class
}
However this also violates some PHP practices, with extends normally meaning a special case of which user options doesn't appear to be.
My final way of organising the document uses in the default class to seperate the large file down, for example:
classes/user.php
class User {
/**
* CREATION SECTION
*/
public function create() {
//create user
}
/**
* UPDATE SECTION
*/
public function change($whattochange) {
//what to change
}
}
However this once again seems to violate the single responsibility principle, with a lot of options being in one single class.
What is common practice to separate down a class, and how should it be done?
The current User class has the following methods inside of it:
* - $variables
* - __construct gets a new user.
* - stripeCustomer() gets the customer information if it exists
* - create($fields|array) method to create a new user
* - login($username|string, $password|string, $remember|bool) logs in a user
* - find ($param|string, $method|string) finds a user WHERE param=method
* - data() returns user data
* - isLoggedIn() returns whether a user is logged in
* - isAdmin() returns if a user is an admin
* - logout() logs out current user
* - displayName() returns first name or username
* - isVerified() checks if a user is verified
* - inCompany() checks if a user is in a company
* - inVerifiedCompany() checks if a user id in a verified company
* - verifyUser($apicode|string, $verification|string, $resend|bool) verifies a users email
* - error() returns any errors that may occur
* - getProfilePicture($size|int) gets a users profile picture from Gravatar with size of $size in pixels
* - passwordCheck($password|string) checks if two passwords match
*
* // 2FA section
* - has2FA() checks if the user has 2FA enabled
* - TOTP($type|string, $secret|string, $code|string, $backupcodes|array) everything to do with 2FA
* - countBackups() counts the amount of backup codes remaining for a user with 2FA
* - update($statement|string, $params|array, $apicode|string) updates a user
*
* // lockdown system
* - getAttempts() gets amount of attempts to break into a users account
* - isLocked() gets whether the user account is locked
* - addAttempt() adds an attempt to a users account
* - reinstateUser() unlocks a users account
* - shouldShowCaptcha() checks whether a captcha is needed
*
* // codes
* - sendRequest($code|int) sends a request to a users email with a specific code
* - verifyCode($code|string, $type|int) checks a user inputted code to one in the DB
*
* - deleteUser() deletes the specific user
* - makeAdmin() makes the user an admin
* - removeAdmin() removes the user as an admin
* - modify($changes|array, $apicode|string) modifies a user | no idea how this is different to update
I also understand that the database section of the class should be in a seperate mapper class, which would use the same style structure as my initial attempt, this will be changed soon.
Thanks in advance for all help.
For reference, i've had a look on google and found some people asking similar questions, however none seem to answer the question to a great degree.
How to break up a large class

Answer 1

there is a way which is called trait you can make any number of traits and include then in a class.. make seperate files of traits it will make your code easy to read..
What a trait actually is its like a class with lot of methods..
how to use it
the syntax will be something like this..
trait UserOptions{
public function create()
{
// logic goes here
}
public function destroy(){
// logic
}
}
trait UserAdmin{
public function isAdmin(){
return true;
}
}
class User{
// this is how to include traits
use UserOptions , UserAdmin ;
}
now all the methods of all the traits are included in the User class .
That is how we can break down so much of the code

Answer 2

Well, I am not really an expert myself. But I guess the answer to the question has two sides. One is not really technical. Let's start with it.
Refactoring is not a trivial task to do. Refactoring legacy code is twice so (I am not sure that your code is actually legacy one, but I guess the rule holds). Usually done by the people who are experts in their field. And even before they start there are a couple of steps to be done. Firstly, the current behaviour of the system must be documented. Either with some kind of end-to-end (acceptance) tests or by really thorough technical documentation (done by business analytics). Better with both. And only then you can start the process of rewriting. Without this, you simply cannot be sure the system will work as before. It the best case scenario, you will end up with explicit bugs (the ones you can clearly see right away). But you also can end up with some unexpected implicit behaviour, that you might notice only after some time.
Regarding technical side. Now you have so-called God object. It does at least persistence, authentication and authorization. So as you stated SRP (Single responsibility principle) is completely dismissed. So firstly you have to extract entity (business object):
final class User
{
private $id;
private $name;
// ...
public function __construct($id, $name)
{
$this->id = $id;
$this->name = $name;
}
public function id()
{
return $this->id;
}
public function name()
{
return $this->name;
}
}
Then extract repository to persist this entity:
final class UserRepository
{
/**
* \PDO or whatever connection you use.
*/
private $db;
public function __construct(\PDO $db)
{
$this->db = $db;
}
public function findByPk($id): User {}
public function create(User $user) {}
public function update(User $user) {}
public function delete(User $user) {}
}
Extract authentication and authorization into separate services. Even better, use existing packages (you can find many on GitHub).
But again all this is safe to do only if you have the way to ensure that your changes have not broken anything.
There is a book on the subject. To be honest, I have not read it myself yet, but I've listened to the podcast with the author and heard really good reviews. So you can check it out.

Answer 3

Instead of stitching rotten software you should think of a re-design with a migration process. The best is to create a new branch that can cope with old data structures but allows to introduce new (straight) ones. A clean cut is also better than many little migration steps. There's a risk in both: little step take long and each can cause user frustration. A cut can fail and you might need to roll back.