-1

the thing I always use in OOP is method . I never use the property, because I don't know what is their benefit.

here is example. there is no need for properties.

<?php 

    class Foo 
    {
         // don't have to use property   public $price;  public $qty;

        public function my_income($qty, $price)
        {

            return ($qty * $price);

        }

    }

    $foo = new Foo();

    echo $foo->my_income(20, 40);
     ?>

but I read there are something called 'getter setter' that is concern so much on properties like this

class Foo
{
    private $bar;

    public function getBar()
    {
        return $this->bar;
    }

    public function setBar($bar)
    {
        $this->bar = $bar;
    }
}

$foo = new Foo();
$foo->setBar(1);

I don't know why they worry about properties so much. it's not make sense for me. if you want to use variable, you just assign variable outside of class or put value in function argument.

doflamingo
  • 567
  • 5
  • 23
  • 9
    _"you just assign variable outside of class"_ - Well, that's kind of the point with properties, that you _don't_ want to clutter the global namespace with variables and use `global` to access them. What if you have 10 libraries that uses the same variable names? Then all of them will overwrite the same variable. I recommend reading a more in-depth tutorial about OOP to get an understanding of what it actually is and when/why/how it should be used. – M. Eriksson Apr 13 '17 at 07:52
  • 1
    The `Foo` class in your first example is just a useless wrapper around the `my_income()` function. – axiac Apr 13 '17 at 07:52
  • I think in this link it is explained pretty well http://stackoverflow.com/questions/1568091/why-use-getters-and-setters?answertab=active#tab-top – Eimsas Apr 13 '17 at 07:53
  • 1
    oh.... encapsulation – Alon Eitan Apr 13 '17 at 07:55
  • 3
    Dogs have 2 eyes and 4 legs; these are a couple of properties of dogs. If you were to model a dog in code number of legs and eyes would be a couple of properties shared by **all** dogs - these become class properties - every time you instantiate a `new Dog()` it has legs and eyes, Now, if your dog loses a leg in an accident, you can update your dog with the setter method. Fish have no legs so when creating `new Fish()` you don't care about the number of legs - it's not a global property... – CD001 Apr 13 '17 at 07:56

3 Answers3

4

There's no reason to use properties in that specific example, but object properties are hugely useful.

For instance, a Person class with someone's name and age:

class Person {

    private $name;
    private $age;

    public function __construct($name, $age) {
        $this->name = $name;
        $this->age = $age;
    }

    public function about() {
        return $this->name . " is " . $this->age . " years old";
    }
}

$joe = new Person("Joe", 42);
$alice = new Person("Alice", 27);
echo $joe->about(); // "Joe is 42 years old"
echo $alice->about(); // "Alice is 27 years old"

By grouping the data for the person together in one place (the object), we make it much easier to pass that data around.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • The `Person::about` could be converted into `__toString()` magic method, and the output should be **Joe is 42 years old**. But your answer is great anyway – Alon Eitan Apr 13 '17 at 08:04
1

its all about encapsulating the data going around your script. This means giving it an 'owner'. This prevents data being accidentally overwritten or altered.

A class encapsulates everything inside it. Everything gets a 'visibility', so private, protected, public.

Consider this example:

class Car {
        // no properties but some other methods you might want.
     public function someUtitity($x, $y) {
           return $x + $y;
     }
}



class CarBetter {
    private $colour;

    private $engineSize;

    public function __construct($colour, $engineSize) {
        $this->colour = $colour;
        $this->engineSize = $engineSize;
    }

    public function getColour() {
        return $this->colour;
    }

    public function getEngineSize() {
        return $this->engineSize;
    }

    public function setColour($colour) {
        $this->colour = $colour;
    }

    public function setEngineSize($es) {
        $this->engineSize = $es;
    }

}

Class Car is simply a utility class, it cannot actually represent an object of type Car because it can contain no data thats individual to that instance.

Class CarBetter is a proper representation of the the Car model. It contains all the things you need to know about the car. They can only be changed by accessing the class directly, via its getters and setters.

Now when I want to pass this instance of Car around my script its easy, and I can be sure that all its relevant data is encapsulated inside it. (Think capsule with spacemen in it if it makes it easier).

Now, I can have multiple instances of an object CarBetter, each with its own specific data. None of that data can be changed unless its accessed directly through the class methods.

DevDonkey
  • 4,835
  • 2
  • 27
  • 41
1

The problem: data structures and methods that can work on them.

In your case you have two values which appear to belong together, a quantity and a price. You could always keep them around in two separate variables:

$qty = 20;
$price = 40;

And then all functions that use that data accept two arguments:

function income($qty, $price) { ... }

What about data structures that require a bit more than two fields, say a product description; are you going to keep all those as individual variables?

$product_name = 'Foo';
$product_price = 400;
$product_description = 'Lorem ipsum';
...

There are typically dozens of properties a product has; will you keep an individual variable for each, and have each function accept dozens of arguments?

function display_product($product_name, $product_price, $product_description, ...) { ... }

That's pretty impractical.

So you define an actual data structure that you can carry around in a single variable:

$product = [
    'name' => 'Foo',
    'price' => 400,
    ...
];

Now each function that works with product data only needs to accept a single argument which contains all the data:

function tax(array $product) {
    return $product['price'] * 0.08;
}

But you still have disparate data definitions; your $product array structure is defined over here, but there may be any number of functions defined over there, and if you change something about one or the other they might stop working together correctly. So, let's bundle them up into one thing!

class Product {
    public $name;
    public $price;
    public $description;
    ...

    public function tax() {
        return $this->price * 0.08;
    }
}

The tax method works on specific product data, and it's bundled together with the actual data it's working on, so there's little chance of these two pieces diverging.

That's the basis of OOP and the use of properties. More interesting use cases can be build on that; e.g. polymorphism, which isn't really practical using only functions and variables.

deceze
  • 510,633
  • 85
  • 743
  • 889