Instantiate an object with only some of its members - php

Question

I'm working in an PHP application, and I'd like to be able to instantiate an object, but I need it to get instantiated only with SOME of it's properties, not all of them. Eg.
class User {
public function __construct() {
$this->user_id = 0;
$this->name = '';
$this->profile = array();
//...many other members here
}
}
Every time I instantiate this object it brings many collections of data, (for example, it brings all it's "profile" properties and so on). And this is sometimes not the wanted behavior because, let's say I need to use only the name of the user, why having in memory all the rest of the properties? But in other cases, I will need them all right away.
Some ideas:
I could create another class that extends User, and in the constructor method unset any unwanted properties. However, I'm looking for a more reusable way, so I can do the same with some other objects in my application.
I could take the properties out of the constructor method, but this would probably force me to change the core of the application (classes above User class), and alter many things in the application.
Is there a more reusable way like using an standard intermediary class or some design pattern?
Thank you.

Answer 1

The Keywords you are looking for are eager loading vs lazy loading.
In Short:
Eager Loading is what you are doing at the Moment: Once an object is created, you are loading all related objects and attributes, no matter how Long it takes.
Lazy loading is the opposite: There you will ONLY load Information, when it is required. (The Moment, it is really accessed)
--
A (very Basic) implementation of both would look like the example bellow.
//Data Model
abstract class UserModel{
protected $userData = null;
protected $userPosts = null;
protected function loadUserData(){
//do whatever required and store in $result
$this->userData = $result;
}
protected function loadUserPosts(){
//do whatever required and store in $result
$this->userPosts = $result;
}
public abstract function getUserData();
public abstract function getUserPosts();
}
//Eager Loading
class EagerUserModel extends UserModel {
public function __construct() {
$this->loadUserData()
$this->loadUserPosts();
}
public function getUserData(){
return $this->userData;
}
public function getUserPosts(){
return $this->userPosts;
}
}
//Lazy Loading
class LazyUserModel extends UserModel {
public function __construct() {
//do nothing
}
public function getUserData(){
if ($this->userData == null){
$this->loadUserData();
}
return $this->userData;
}
public function getUserPosts(){
if ($this->userPosts== null){
$this->loadUserPosts();
}
return $this->userPosts;
}
}
The Example will allow BOTH ways. However you could implement either eager or lazy loading within a single class, if you dont want to have the "choice", of which type to use.
Eager Loading has the Advantage that EVERY Information is "just there". Lazy Loading however requires a more complex architecture. To load the "UserPosts", you might require additional data about the user, which means you have to load the UserData first. This is something you Need to take into account!
So, Lazy loading is always faster?
No! That's the pitfall. Imagine, you have a class with 10 Attributes. If you are loading every Attribute in a lazy way, that would require 10 SQL-Queries to be fired (SELECT Name FROM user..., SELECT email FROM user... and so on). Doing this in an Eager way, would allow you to run only ONE Query: Select Name, email FROM user....
You have to find the Balance between both methods. Are Foreign Objects tightly Coupled? (I.e. user <-> Group)? -> Load Eager. Are foreign objects loosely coupled (User -> Posts on Image 545458) -> Load lazy.
Also Note, that this is an extreme example (100% eager vs 100% lazy). In practice, you may want to load some things eager (user data, Group allocation), and others lazy (comments, Group permissions) - You cant create a own Extension of the base class for every usecase. However having a "BaseClass" is always a good idea, because it gives you flexibility, whenever another implementation is required.

Answer 2

One way to go about it would to create a base-class that contains as little specialization as possible for it to work. Extending the base class and incrementally adding properties/features as needed would allow you to control what gets added.
This would conform to generally accepted object-oriented design patterns.

Answer 3

If you have entity written properly, I prefer to keep it and not to be worry about some empty properties, if the entity keeps its consistent state missing some values. If you don't need them, don't use them. If your script is more complex or long time running, take care of destructing objects when you don't need them anymore.
If the entity can be generalized to more common entity and to be used as base class for other entity later, and makes it sense, then go this way. This would be more difficult way, because refactoring would be needed.
You can also use object composition, when user entity keeps only main user data and one of value will be prepared for another object named profile, for example:
class User {
public function __construct() {
$this->user_id = 0;
$this->name = '';
$this->profile = null;
}
public function hasProfile()
{
return $this->profile != null;
}
}
class Profile {
public function __construct() {
$this->profile_id = 0;
$this->userPrefOne = '';
//...other members here
}
}
// then
$user = new User();
if ($profileDataNeeded)
{
$user->profile = new Profile();
$user->profile->userPrefOne = 'something';
}