Object-oriented – OOP implementation doubts with databases

classdatabaseobject-orientedPHP

I was starting a project today and after designing the database structure and how the data would be stored etc, I started the implementation. I am doing this on php, but the language isn't really relevant here, since my doubts are more architectured related or I guess, since I'm struggling more than I thought by implenting stuff in OOP on PHP. (Recently jumped on php, I've been coding in c++ and java before).

So, I started by creating my "User" class, simple as that, few attributes, and __construct, insert, update and delete methods. Those last 3, queries to the db.

Then this doubt came to my head, and I probably know the answer myself but I just don't find out.

I can now create instances and create new Users: $user = new User("John", 34) but, what if I want to edit the user "Dave"? Or I want to show all users. That method, for example, getAllUsers() which would return all users where would be implemented? Because it doesn't really belong to the class User right? If it did, then how I would instance that method if I don't have any User instance?

I guess, I would need a class Users, or UserCollection which would be a collection of all the users, with the methods ´getCertainUser(id)´ and ´getAllUsers()´ which would return certain User or All of them, now then I would have a User I would be able to edit.
That is the way I've did in both Java and C++, since I didn't use a database to store the data, it was stored on a Set/Map or whatever the structure, and then saved on files.

That being said, my questions is, how this problem should be addressed as the way to go, Am I complicating things too much? How this should be solved 'the correct way' in OOP. The times I've handled similar problems I've never used a database, so having a collection of users was the only way to store them, but having the database which stores the users feels redundant to have that collection of users.

Thanks in advance.

Best Answer

The problem should be addressed by separating concerns

Here is what I mean.

The reason why you have a bad feeling about adding the getAllUsers() to the User class is because it is too much responsibility for that class. This could convolute things down the line - especially when trying to test things.

My suggesting would be to rethink the way you are doing it.

Instead of making the User class know about all of those things such as inserting itself, updating itself and maybe returning all of the users - make it instead a DTO object that doesn't know about anything.

Then have a UserManager that takes in that DTO which can insert it into the database, update it, delete it and have a UserReader or UserRetriever (or some other name that gets the point across) that either returns back all users as a list of DTOs or a specific user based on the id.

This way it makes testing easier and makes sense conceptually which is key when - you want others to contribute to the project or just maintain it yourself.

Related Solutions

PHP OOP – Simple Real-World PHP OOP Example

The problem with Object Oriented Programming is exactly that, the shape and vehicle examples. What I'm going to type below is not the actual truth, it is an opinion. An opinion shared by more people than just me though :)

Object oriented vs "Class oriented"

Your example where there would be a catalog and an episode is perfectly well. The problem is the functions you propose these Objects should get. That is where you go from Object Oriented Programming to Class Oriented Programming. Just fitting a lot of methods concerning the same concept in an Object doesn't make programming object oriented. All you do is make some sort of container for methods.

The Episode Object should be just an Object that "models" the Episode. It has a title, content, author, that kind of stuff. In no way should this Episode have access to the database. It is not supposed to save itself or be able to load more instances of other episodes. The same goes for Catalog, it should not be able to retrieve its newest Episode itself. A catalog is a model, it has a title and some other stuff.

Splitting up responsibilities

Getting stuff from and saving stuff to a DataBase is not a models responsibility. So someone else has to do the job. A good start might be to create a CatalogRepository which could look like so:

CatalogRepository
{
    /**
     * @param int $id
     * @return Catalog
     */
    public function getCatalogById($id)
    {
        //Do a query, populate a new Catalog and return it. 
        //The constructor of Catalog should not be the one quering! 
        //It should receive data, nothing more
    }

    /**
     * @param Catalog $Catalog
     */    
    public function saveCatalog(Catalog $Catalog)
    {
        //stuff....
    }

    /**
     * @param string $name
     * @return Catalog[]
     */    
    public function searchCatalogsByName($name)
    {
        //do a full text search or something?
    }
}

The Episode would have something along the same lines where you could get all Episodes for a specific Catalog but also the five most popular Episodes:

class EpisodeRepository
{
    /**
     * @param Catalog $Catalog
     * @return Episode[]
     */
    public function getEpisodesByCatalog(Catalog $Catalog)
    {

    }

    /**
     * @param int $amount
     * @return Episode[]
     */
    public function getMostPopularEpisodes($amount)
    {

    }
}

There are some really good guidelines for writing good object oriented code, take a look at SOLID for instance

PHP OOP – Should Every Object Contain All the Data?

There are a few different approaches you can use to do this, depending on the data set, performance needs, and your general preference.

If there's an object that is used almost exclusively for display, you would probably want to query the dataset beforehand in some sort of Factory and then create the object by passing the data into the constructor.

If there's an object that touches a bunch of data sources and is used for different things, loading all of the data at instantiation might take a long time, and all of the object's data might not be needed every time that object is instantiated. You can leverage lazy loading to accomplish this goal.

If performance is a major concern, and the object stores a ton of data but is mostly immutable, you can use something like the Flyweight pattern, which allows you to actually treat a single object like a collection.

I highly recommend you try a few different ways of doing things. For a project such as yours, how you choose to instantiate and populate the object will probably matter little, but it will be a good and fun exercise in different object instantiation patterns.

As a final note, much of the knowledge you're gaining now about OOP can be applied to nearly any language you learn in the future.

Best Answer

Related Solutions

PHP OOP – Simple Real-World PHP OOP Example

PHP OOP – Should Every Object Contain All the Data?

Related Topic