Jump to content

Imposing Specifications Inside of Class Scope


BrandonK

Recommended Posts

I know that it is possible to define a __set() method inside a class so that any variable declarations must go through that function.  Inside of that __set() method I am able to impose a specification class for certain variables that I need to.  This all works great... My question is, can I do this inside the class scope also?  I want to make sure that it is impossible for me (or any other programmer that may join the project) to set an illegal value for certain variables.  Some are as simple as requiring numeric or certain datatypes, while some must match specific regular expressions.

 

To show some code, here's what I'm asking about:

<?php


class StrictTest {
public $pub_id;
protected $pro_id;

public function __set($property, $value) {
	$method = 'set'.ucwords($property);
	if (method_exists(__CLASS__, $method)) return $this->$method($value);
	else $this->$property = $value;

	return true;
}

public function setPub_id($value) {
	if (is_numeric($value) && (int)$value > 0) {
		$this->pub_id = (int)$value;

		return true;
	}

	return false;
}
private function setPro_id($value) {
	if (is_numeric($value) && (int)$value > 0) {
		$this->pro_id = (int)$value;

		return true;
	}

	return false;
}

public function testPro($value) {
	return $this->pro_id = $value;
}
}

$t = new StrictTest;
$t->pro_id = 'String';
$t->pub_id = 'String';

var_dump($t);

$t->testPro('String');

var_dump($t);

?>

 

When the protected property pro_id is called from outside of the class scope, the setter is used correctly.  However, since pub_id is public, there is direct access to the variable and that bypasses the setting.  Inside of the class scope, direct access is granted to the protected property, and again the setter is bypassed.  Anyway to solve this?

Is this an attempt to make PHP a strong typed language?

 

It may be simpler to create a rule that people have to use the defined methods to set your properties...thats just my way of saying that I dont have an answer for your question. :)

 

If you want all fo the properties to use the setter, why declare some as public? Set them all to either private or protected and when you need to change or retrieve them, use simple getters and setters

The public properties were simply there for examples.  I rarely declare object properties and public because I like to make my objects closed so that I can control access using various forms of getters.  Its easy to say that all access to variables must use a getter/setter, but I was more curious if its possible to enforce that rule.

 

I am not trying to make PHP a strong typed language.  I am simply trying to add extra security to my program.  For example, certain variables cannot be changed once they are initiated.  One of my objects is a product class.  If I change the id of the product in the middle of processing the object, I may start getting information from two separate products at once... While its easy to say "well don't change that id ever", but accidents do happen (especially when new programmers join a project).

Might sound daft and cumbersome, but could you create another class (static maybe) that holds all the constants, and then give that class get methods, and use those?

 

<?php
class Constants {
  private $constant_1 = 3;
  private $constant_2 = "my_string";

  private $constant_1_max = 10;
  private $constant_2_max_length = 100;
  
  private $defaultConstant_1 = 10;
  private $defaultConstant_2 = false;

  public function getConstant_1() {
    if ($this->constant_1 > $this->constant_1_max) {
      return $this->constant_1;
    } else {
      return $this->defaultConstant_1;
    }
  }
  
  public function getConstant_2 {
    if (count($this->constant_2) <= $this->constant_2_max_length){
  return $this->constant_2;
} else {
  return $this->default_constant_2;
}
  }
}
?>

Other than that I don't know - I doubt you one can have fields available to one method and not another within a class.

 

BWT I haven't tested this at all, so it probably won't even compile...

Honestly for myself, i believe that __set and __get are bad features of the new PHP5, and not implemented correctly they can cause funny behaviour especially when you have extended classes that all of a sudden have public variables that you didn't want public. It also makes it a bit of a blackbox scenario where someone else might be unsure if they can set a particular internal by attempting to use $foo->bar = "blah"; whereas in a normal ide environment they should be able to dropdown a list of valid functions and choose which one is appropriate.

 

Introducing the lazy man approach (with __set and __get) might cause you more problems that it's worth. Especially if someone creates an extended class and creates a private function called setMyParam() which should only be used internally (by the class) but one of the other programmers just takes a guess and does $foo->MyParam = "blah"; thinking it exhibits some other behaviour.

 

Just my 2 pence, but thought I should say it...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.