Extends? Implements? Private, Public, Protected?

Aaron · 05-04-2008, 07:38 AM

I am having an extremely hard time figuring out the scope of methods, parameters, and classes.

Why would you need to extend something, would you need to extend it to access a public function, why private functions, why protected, why does nobody use protected, what is implements, why would you need to implement something. How do you know that something doesn't belong in the class you are developing (like, a USER class that pretty much uses nothing but the database)

Oh, and totally irrelevant to the topic, how can you code in OOP without bloating your stuff to all hell?

And another thing: Wouldn't using like.. Zend, Smarty, and Jquery totally bloat your application?

SOCK · 05-04-2008, 08:50 AM

Quote:

Originally Posted by Aaron

Why would you need to extend something, would you need to extend it to access a public function, why private functions, why protected, why does nobody use protected, what is implements, why would you need to implement something. How do you know that something doesn't belong in the class you are developing (like, a USER class that pretty much uses nothing but the database)

All very basic OO concepts. Take a look at some tutorials, particularly the ones on Java as PHP's current OO implementation resembles Java quite a bit, I think.

Public properties (methods or data) allow access from anywhere in the script, e.g.

PHP Code:


			
// 'Car' class allows access to it's 'NumberOfDoors' property

$car= new Car();

// show a property in it's default state - allowed

echo $car->NumberOfDoors;

// alter the property - allowed

$car->NumberOfDoors= 3;

// show the property again - allowed

echo $car->NumberOfDoors;

Protected properties only allow access from within the class or any child classes, e.g.

PHP Code:


			
class Car {

  protected NumberOfDoors;



  public function __construct() {

    $this->NumberOfDoors = 4;

  }



}

// this child class can access any protected member

class EconomyCar extends Car {

  public function __construct() {

    // call the parent constructor and set any defaults

    parent::__construct();

    // alter the NumberOfDoors for this model - allowed

    $this->NumberOfDoors= 3;

  }

}



// instantiate

$car= new EconomyCar();

// show the property - not allowed

echo $car->NumberOfDoors;

// alter the property - not allowed

$car->NumberOfDoors = 4;

Private members are only allowed access from within the parent class.

PHP Code:


			
class Car {

  private NumberOfDoors;



  public function __construct() {

    $this->NumberOfDoors = 4;

  }



}

// this child class can access any protected member

class EconomyCar extends Car {

  public function __construct() {

    // call the parent constructor and set any defaults

    parent::__construct();

    // alter the NumberOfDoors for this model - not allowed

    $this->NumberOfDoors= 3;

  }

}



// instantiate

$car= new EconomyCar();

// show the property - not allowed

echo $car->NumberOfDoors;

// alter the property - not allowed

$car->NumberOfDoors = 4;

In general, you should use the least amount of privilege for any property; IMHO it's a good idea to use protected unless you have reason not to. That way the object properties are kept hidden from the user but not to any child classes.

The reason behind all this is the basic OO concept that objects hide (or encapsulate) the data and methods from the outside world and provide an interface to access them. The Car class NumberOfDoors property should be kept hidden from the user; the person using the class API should be given a set of "controls" to work with the object and hide the internal workings away. Here's an example using the same Car class.

PHP Code:


			
class Car {

  protected NumberOfDoors;



  public function __construct() {

    $this->NumberOfDoors = 4;

  }



  // public interface to alter the number of doors

  // notice how it carefully controls what the user can do

  public function SetNumberOfDoors($num) {

    if ( is_numeric($num) && $num >= 2 && $num <= 5 ) {

      try {

        $this->NumberOfDoors= $num;

      } catch ( Exception $e ) { }

    }

  }



  // public interface to retrieve the number of doors

  public function GetNumberOfDoors() {

    return $this->NumberOfDoors;

  }

}

// this child class can access any protected member

class EconomyCar extends Car {

  public function __construct() {

    // call the parent constructor and set any defaults

    parent::__construct();

    // alter the NumberOfDoors for this model - allowed

    $this->NumberOfDoors= 3;

    // use the 'setter' to alter the number - allowed

    parent::SetNumberOfDoors('3');

  }

}



// instantiate

$car= new EconomyCar();

$car->SetNumberOfDoors('4'); // allowed

$car->NumberOfDoors= 4; // still not allowed

echo $car->NumberOfDoors; // again, not allowed

echo $car->GetNumberOfDoors(); // allowed

These are often called 'setters' and 'getters', or in "real" OO speak they're referred to 'accessors' and 'mutators'. They're the public interface to object data.

I hope this helps your understanding. Please note that the class examples shown are untested.

Quote:

Originally Posted by Aaron

Oh, and totally irrelevant to the topic, how can you code in OOP without bloating your stuff to all hell?

Not even an issue; all you're doing is altering your process and encapsulating the data with the behavior in a neat little package. It's no different than writing procedural functions and passing data in and out. Frameworks are a different issue, and I can't really comment because I don't use them. I still don't see it as being a problem.

Aaron · 05-04-2008, 04:20 PM

Ehh, okay...

That cleared up the protected function for me, but my actual problem was the weird Class::selectorthing. Like, if your class extends another class, you can use $this-> to access anything, but should you use Class::? does Class:: do anything different from $this->?

And then theres the implements thing... I'll go read a tutorial for that...

And so you don't need to extend something to use a public function?

I read somewhere that you shouldn't edit or use the properties of a class in your script, is that true?

What do you do if you need to extend two classes?

SOCK · 05-04-2008, 09:20 PM

Quote:

Originally Posted by Aaron

That cleared up the protected function for me, but my actual problem was the weird Class::selectorthing. Like, if your class extends another class, you can use $this-> to access anything, but should you use Class::? does Class:: do anything different from $this->?

The $this keyword represents the currently instantiated object. Due to the fact that the class is simply the blueprint for the object, there has to be a way to access the 'object name' inside the class definition itself. So when you say $this->something or $this->innerMethod(), you're allowing the object to interact with itself internally.

Using the 'scope resolution operator' (::) references a static member, constant or parent class, as in my example above where I'm referencing the parent class constructor using parent::__construct(). It's a way to access those properties without having an instantiated object. In other words, if you instantiate the 'EconomyCar' class, you have all the attributes of the 'Car' class (such as the constructor), but they're overriden by the 'EconomyCar' class. If you want to call the parent's version of that method you use the '::' operator.

It's most often seen in use with static method calls, e.g.

PHP Code:


			
class OutputHTML {
  public static function createForm($e,$i=FALSE,$iNames=null) {
    $tmpForm="<form id={$e} name={$e} ";
    $tmpForm.='action="' .htmlentities($_SERVER['PHP_SELF']);
    $tmpForm.='" method="POST">';

    if ( $i == TRUE && is_array($iNames) ) {
      foreach( $iNames AS $t => $n ) {
        $tmpForm.="<input id={$n} name={$n} type={$t} />";
      }
    }

    $tmpForm.= '</form>';

    return $tmpForm;
  }
}

// static class method call without any input elements
// (useless, I know, but flexible)
echo OutputHTML::createForm('form1');
// alternatively, a static method call with input arguments
echo OutputHTML::createForm('form1', TRUE, array('text'=>'name'));

So notice that you have a public and static method declaration that you have to access with the '::' operator; you cannot use this method if you create an instance of this class. Yes, it's technically possible in this state to instantiate an object of the 'OutputHTML' class, but it can't do anything, as there are no non-static members declared. You can actually declare a private, static constructor and force the user to only call this class statically. This is useful when implementing the singleton pattern.

At any rate, when you call the ClassName::StaticMethod() in this way, it immediately performs whatever task it is meant to do and then dissapears like any regular function call. There is no object.

Quote:

Originally Posted by Aaron

And so you don't need to extend something to use a public function?

No, a class doesn't need to be extended at all. Public means the class / object attributes can be accessed by any other class, function or other parameter in the script.

Quote:

Originally Posted by Aaron

I read somewhere that you shouldn't edit or use the properties of a class in your script, is that true?

Yes, this is what I was referring to as data hiding or encapsulation and providing the user an interface to work with.

Quote:

Originally Posted by Aaron

What do you do if you need to extend two classes?

Not currently possible in PHP.

I don't know if you've read through the PHP manual section on v5 objects & classes, but it explains everything here and more.

Aaron · 05-05-2008, 12:18 AM

Ive read skimmed through like 12 guides on the scope of this stuff and I still don't get it. I mean, basic public/private/protected stuff I get. Extension means that you inherit the properties and methods from a class, so that gives you access to the private methods, right?

Abstract... That sounds pointless to me. It allows for empty methods? Woopdie doo :/

Static? Meh, again, no use seen.

Implementation?
ewww. It is nothing but a list of methods. I is disgusted.

It just seems like there isn't much of a point.

SOCK · 05-05-2008, 01:10 AM

Quote:

Originally Posted by Aaron

Extension means that you inherit the properties and methods from a class, so that gives you access to the private methods, right?

Yes, extending a class means your child classes inherit all properties and methods. No, if they are declared private, then only the parent class has access to them. This is why I recommend to give them the protected visibility so derived classes can still have access to those properties. Note that even private properties are inherited, they're just not accessible.

Quote:

Originally Posted by Aaron

Abstract... That sounds pointless to me. It allows for empty methods? Woopdie doo :/

Static? Meh, again, no use seen.

Actually, abstract classes are a very powerful way to implement what's known as polymorphism, or the ability to use different objects in the same way. This Wikipedia article on Object Oriented programming states that and more.

Think of abstract classes like this: you want to create an object that handles data storage. Period. The interface should be the same regardless of how the class stores data. So you can have an abstract class named 'DataHandler' with methods like 'putData' and 'getData', etc. You can derive this abstract class into a class that interacts with databases, or a class that stores and retrieves data from a flat file. These classes can be further derived into classes that specify what type of database, if the file is XML, JSON or regular text, etc. But the calling object will still use the same 'getData' and 'putData' methods, so it's totally flexible if you should want to switch how you store data.

Static method calls are essential in most OO programming; I use them everyday.

The bottom line; unless you plan on going all OO in your PHP code, or switch to Java or C#, all of this may not be relevant to you.

drewbee · 05-05-2008, 06:44 PM

Very nice sock. I personally use OOP programming as well and couldn't have delivered it more clearer then you have here. Above anything else, OOP helps keep things extremly clean, especially when mixed with a templating engine.

For instance, I use smarty. Smarty is wonderful, and I do not have a single line of HTML code in any of my PHP files. Using this it is possible to truly seperate presentation from the logic layer.

I have a page class, which its sole purpose is to handle sessions, user authentication, and database connections. This class does all the pre-processing for each page without me needing to hard code it into any page. If a page has unique circum stances, I can manipulate the object from the page calling it to make sure it is doing what I want it to do.

I also have a basic form class, that every single one of my forms calls. This form class sets up abstract methods like processForm() and drawForm(). This class also handles auto-protecting against several security issues. So when the child form class is used, I know I do not need to worry about protecting against SQL injection or XSS attacks, as my the parent class takes care of all of this dynamically.

Trust me .... once you go OOP you never go back :) Things are just so much easier to control and organize with it.

sketchMedia · 05-06-2008, 07:52 PM

2 articles on TalkPHP about abstracts and interfaces:

TalkPHP - Using Abstract Classes to Define Rules

TalkPHP - Working with Interfaces

Orc · 05-06-2008, 10:47 PM

Interfaces are for implements, private public protected are for visibility, extends are to join classes.

Aaron · 05-07-2008, 12:47 AM

Okay, for now I have one more question:

How should I organize my classes? Like should I have over 30 in different files, or should I all have them in the same file? Can I call a class from within a method? What is like, the generality that a class should follow, like, if it is about databases, can it use a class like getNavigation, or should I make a new class for all the non-reusable things?

Orc · 05-07-2008, 12:51 AM

Quote:

Originally Posted by Aaron

Okay, for now I have one more question:

How should I organize my classes? Like should I have over 30 in different files, or should I all have them in the same file? Can I call a class from within a method? What is like, the generality that a class should follow, like, if it is about databases, can it use a class like getNavigation, or should I make a new class for all the non-reusable things?

classes are only used for only used in case you have to keep REUSING them. Also, 30 files for what? You can just put them all in one file, it doesn't really matter besides performance issues xD.

Aaron · 05-07-2008, 01:21 AM

LIES! Classes are much easier to use and edit than normal code. They are more easily organized and much easier to manage and maintain and update simply because they are organized in one area, not spread across 90 files.

Orc · 05-07-2008, 02:38 AM

Quote:

Originally Posted by Aaron

LIES! Classes are much easier to use and edit than normal code. They are more easily organized and much easier to manage and maintain and update simply because they are organized in one area, not spread across 90 files.

thats really what i ment xD

delayedinsanity · 05-07-2008, 02:29 AM

It really all depends on what you're trying to do. Is it a project for yourself, or one intended for the open source community? or one to be sold? Is it something you want other people to be able to extend, or is it going to be a complete package? Is it huge, as in enterprise scale, or is it small, home page kind of stuff?

There's a lot of different reasons to implement things in various ways. I've been bitten by the OOP bug, but I do recognize there's cases when procedural code is just as good, so be careful you don't completely come over to the dark side. There's always more than one way to do something.

At the same time, classes aren't only useful for code you plan to reuse in different projects, so I have to disagree with Orc on that one. They're a great way for methods and properties to co-exist that all rely on one another or that work together in some fashion.

Personally, I have all my classes in seperate files, because I find it functional and organized. The downfall to this, is the overhead created by include()ing each class file individually as necessary. Including one file each time would be way less overhead, but the downfall there is, what if you don't need each class everytime? Then the overhead comes in the total filesize of each script the user is loading.

So it all comes down to what you're doing, and what the most important objective of your project is.
-m