Its been awhile since I've touched base on my PhP skill, I could use a refresher on what a class is and what an object is to a class

@jwavess

check out this: https://laracasts.com/series/object-oriented-bootcamp-in-php

the first lesson is called classes, has to be on point with what your asking.

Hey Seth,

I will strongly second the series @jbowman99 recommended, and in fact I'd say you should watch it through completely before you worry about any of the others.

In the simplest terms.. A class is the definition of a thing, and operations it can perform. An object is an instance of that class.

So, in real physical world terms, you could think about a class that defines an animal. What properties does an animal have, and what kinds of things can it do? The class is .. essentially the rules for what makes an animal an animal, and not a chair. The animal itself is the 'object'.

That's a little abstract, so trying to be a bit more on the nose, think about dogs. We could write a class that defines the characteristics of a dog:

A dog might have the following properties:

• size (small, medium, large)
• color (brown, white, spotted, etc)
• weight
• gender

A dog also would have some basic functions that it performs (class methods):

• Bark
• Eat
• Tail wag

Now, of course there are lots of different kinds of dog, different breeds, etc.. but if you have two dogs in front of you, physically, they would represent two separate instances of the dog class. They are completely separate individual dogs (objects), that share similar characteristics... all dogs have a gender, size, weight and color. all dogs (probably) can eat, bark, and wag their tail. Given the terms we used to define dogs in our class, those are the characteristics that make a dog, a dog.

Certainly the rabbit hole goes much deeper than that, once you start getting into sub classes, abstract classes, inheritance, etc.. but really, those are the basics. Its only really as complex as you let yourself feel it is. :)

Now, go watch that OO bootcamp series. It's hands down one of the absolute best series on the site! :)

@willvincent Awesome Will, That totally confirms what I thought classes and objects are. I do recall inheritance and a few other things. I recall functions inside classes are called methods. Im currently taking the Pluralsight PhP course's section on classes. Then Ill watch Jeffreys and then the Team Treehouse section, just to drill it in my brain. I should tag you in my questions for now on, great answers!

Seth

I have an odd piece of advice:

Don't worry too much about "the correct definition" of a class, or an object. None of the definitions I've heard really "fit" my experience of using OOP. All the definitions feel a bit artificial.

At a basic level, classes are just a convenient way to separate logic and avoid naming collisions. Imagine if your computer only had one folder, and all your files went in there. It would break down rapidly, because you would have lots of files with the same name in the same folder. Well, that's a bit like using procedural (non-OOP) code. Once you have used a function name, you can never make another function with the same name.

When you use OOP, the classes are a bit like folders on your computer. You can have two different classes, each of which has a method (function) called update() (for example).

But in larger projects, you will often find classes that have the same name. Namespacing is simply a way to solve that issue.

Classes themselves don't do much. They are like blueprints for making objects. You can make multiple "copies" (or instances) of a class by instantiating multiple objects. For example, on Laracasts Jeffrey will have a User class. But there are many different users, such as you and me. We have the same blueprint, but we are different. For example, all users have an email address, but yours is different from mine.

However, you don't always have to make multiple instances of a class. Even if you only have one instance, classes are still a useful way of keeping your logic organised. Classes can be used for all kinds of things.

For example, I have a class called VimeoSynchroniser, which updates my application with the latest data from my Vimeo account. Now, I only ever need one of these at a time, but it's still convenient to have that logic wrapped in a class. For one thing, it avoids naming collisions. But also, it's good to have a separation between how the class is used and the code that makes it work.

For example, here is how that class is used in my controller:

use BadmintonBible\Core\Http\Controller;
use BadmintonBible\Content\Management\Videos\VimeoSynchroniser;

class ContentAdminController extends Controller {

    private $vimeo;

    public function __construct( VimeoSynchroniser $vimeo )
    {
        $this->vimeo = $vimeo;
    }

    public function getCreate()
    {
        $this->vimeo->syncChanged();

        return view( 'content.management::content.create' );
    }

(By the way, that bit at the top in the constructor is an example of type hinting. Type hinting is just saying, "I want one of these things, make it for me please. And it must be the right type of thing, not just some random crap".)

Note the line, $this->vimeo->syncChanged(). This is saying, "Go get the latest information from Vimeo for me". And it's only one line of code.

But if you looked inside the VimeoSynchroniser class, you'd see about 140 lines of code to make that work. It does all sorts of stuff: fetching data from the Vimeo API, comparing it to data on my own database, working out what needs to be updated, and then making the database changes.

But when I'm using it in the controller, all of that complexity is hidden behind one line of code. This is the most important thing about OOP: it helps you stay organised and hide complexity. It helps you work on one thing at a time, and then move on.

I think the best way to "get" OOP is just to start using it.

@MikeHopley Thanks mike! That did give me a very different perspective as to how to use classes!

Seth

Glad to help. :) I hope I'm not talking a bunch of confusing nonsense. ;)

One thing I remember when I was starting OOP: none of the tutorials or examples really helped me to "get" it. It was only when I took some of my own procedural code and rewrote it in OOP that I started to understand.

Admittedly that first bit of OOP was pretty awful, but it was my awful OOP. It gets better with experience.

I do wish Jeffrey's introduction to OOP series had been available at the time. It is by far the best I've seen.