OOP concept understanding

Question

I recently started learning the basics of OOP in PHP.

I am new to a whole lot of concepts.

In the traditional procedural way of doing things, if I had a repetitive task, I wrote a function and called it each time.

Since this seems to be a regular occurence, I created a small library of 5-10 functions, which I included in my procedural projects and used.

In OOP, what is the valid way of using your functions and having them accessible from all objects?

To make things closer to the real world, I created a thumbnail class, that takes an image filename as an argument and can perform some operations on it.

In procedural programming. when I had a function for creating thumbnails, I also had a function to create a random md5 string, check a given folder if said string existed, and repeat if it did, so I could generate a unique name for my thumbnails before saving them.

But if I wanted to generate another unique name for another purpose, say saving a text file, I could call that function again.

So, long story short, what is the valid OOP way to have the method randomise_and_check($filename) (and all other methods in my library) accessible from all the objects in my application?

Answer 1

Great question. The first thing you want to do is identify the primary objects you will be working with. An easy way to do this is to identify all the nouns related to your project. In your example it sounds like you will be working with images and strings, from this we can create two classes which will contain related attributes (functions, member variables, etc). And as you wisely mentioned, we need to ensure that the algorithms you are converting into OOP can be called from any context, so we try to keep them abstract as possible (within reason).

So for your specific situation I would suggest something like:

// Good object reference, abstract enough to cover any type of image
//  But specific enough to provide semantic API calls
class Image
{
    // Using your example, but to ensure you follow the DRY principle
    //  (Don't repeat yourself) this method should be broken up into two
    //  separate methods
    public static function randomise_and_check($fileUri)
    {
        // Your code here
        ....

        // Example of call to another class from within this class
        $hash = String::generateHash();
    }    
}

// Very abstract, but allows this class to grow over time, by adding more 
//  string related methods
class String
{
    public static function generateHash()
    {
        return md5(rand());
    }
}

// Calling code example
$imageStats = Image::radomise_and_check($fileUri);

There are several other approaches and ideas that can be employed, such as whether or not to instantiate objects, or whether we should create a parent class from which we can extend, but these concepts will become evident over time and with practice. I think the code snippet provided should give you a good idea what you can do to make the jump from procedural to OOP. And, as always, don't forget to read the docs for more info.

-- Update --

Adding an OOP example:

class Image
{
    protected $sourceUri;

    public function setSourceUri($sourceUri)
    {
        $this->sourceUri = $sourceUri;
    }

    public function generateThumb()
    {
        return YourGenerator::resize($this->getSourceUri);
    }
}

$image = new Image();

$image->setSourceUri($imageUri);

$thumbnail = $image->generateThumbnail();