3

I have started using OOP in PHP recently. For every model, I create two classes. One class for read operations and another Manager class for all the create / update / delete operations. For example,

<?php
// This is a sample class, just to convey the idea
class Image {
    public static function loadById() {}
    public static function loadByName() {}
    public static function search() {}

    public function __construct () {}
    public function __get () {}
    public function getData() {}
    public function getRating() {}
    public function getSimilar() {}
    public function getRelatedNews() {}
}

class ImageManager extends Image {
    public function __construct() {}
    public function __set() {}
    public function remove() {}
    public function update() {}
    public function save() {}
    private function updateSomethingElse() {}
}
?>

The reason I separated this into two classes was that I thought it was a bit more secure, since it did not expose the C/U/D methods to a normal user. Also, I thought this might be faster / memory efficient since I am loading only the smaller class for 95% of the requests. But now I think these reasons are too insignificant for maintaining two files.

Is this a bad practice? Normally, the Manager classes are loaded only during admin operations. User actions rarely update the database (except maybe during a rating operation, or a cron job for updating view count). Should I combine both the classes into the Image class?

2
  • The obvious question here is: why? What's the benefit of separating this into two classes?
    – yannis
    Commented Mar 16, 2013 at 10:15
  • The reason I used this pattern was that I thought it was a bit more secure, since it did not expose the C/U/D methods to a normal user. Also, I thought this might be faster / memory efficient since I am loading only the smaller class for 95% of the requests. But now I think they are too insignificant reasons for maintaining two files.
    – Joyce Babu
    Commented Mar 16, 2013 at 11:20

2 Answers 2

2

This looks a bit like a DCI architecture. So similar structuring is used by some people . It has some advantages related to security and having to "maintain" more files is often enough the better thing compared to a single file with lots of functions. I split them sometimes just for that reason.

Though I wouldn't expect much for speed or memory. Your framework or whatever you use should cache your project in memory anyway and loading a single image is most likely using more memory and taking more time than those few bytes.

2

My two cents. It is a good idea to separate "executors" from "targets of executions" in general. This is the main idea of the MVC paradigm, and perfectly summarized by the Single responsibility principle in object oriented programming (for the other "laws" see here).

In your case though, you are not really doing that. Your ImageManager doesn't really have the only responsibility of C/U/D your Image(s). It also gets the rating, gets the similar (images saved somewhere?) and (I believe) stores the image data. That is because it inherits Image (I think I've just heard something :D).

What I would do, which is more verbose but much more modular, flexible and SOLID, would be to store all my data in an ImageStorage class and then have many *Managers which accept an ImageStorage (or array of them) as input and perform their operations on it (them).

However, your first thought is correct (imho), not bad pratice at all. You should expand this idea and start writing OO code this way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.