Глядя на стоимость объекта Я заметил, что большинство шаблонов используют отдельные функции получения и установки свойств, которые скучно писать и предоставляют множество возможностей для ошибок опечаток.
Есть ли причина писать в этом стиле, а не в обычной процедуре get / set? Это шаблон, который я использую:
class ValueObject{
protected $property1;
protected $property2;
protected $property3;
public function get( $propname ){
if( property_exists( "ValueObject", $propname ) ){
return $this->$propname;
}
}
public function set( $propname, $value ){
if( property_exists( "ValueObject", $propname ) ){
return( $this->$propname = $value );
}
}
}
Идея геттеров и сеттеров довольно интересна.
Давайте предположим, что у нас есть пользовательский объект с именем пользователя, именем, фамилией и возрастом, что-то вроде этого
class User()
{
public $username = 'special!';
public $firstname= 'johnny';
public $lastname = 'frecko';
public $age = 55;
}
Все хорошо, и если мы создадим новый объект внутри $user
переменная, мы можем с радостью назвать $user->age
чтобы получить и установить имя.
Теперь, позже, вы решили, что по особой причине вы хотите установить возраст пользователя на основе формулы, формула зависит от возраста самого пользователя!
В нашем небольшом упражнении возраст пользователя — это его фактический возраст минус сумма длины его имени!
Вы не можете изменять другие методы в вашей программе. Они все связаны друг с другом, вы не можете создать новую переменную экземпляра, не переписывая все, и что вы делаете?
Вы пишете геттер с самого начала. Что-то вроде
function getAge()
{
return $this->age;
}
Это тривиально и скучно писать. Но теперь, если нам нужно исправить переменную age для всей нашей программы, решение так же просто, как добавить некоторый код в геттер:
function getAge()
{
return $this->age - strlen($this->firstname);
}
Нам не нужно ничего переписывать на самом деле, только этот маленький кусочек кода.
Причина, по которой вы пишете геттеры и сеттеры ПЕРЕД тем, что вы даже понимаете, что они вам нужны, заключается в том, что мы, люди, очень плохо планируем заранее, и это дает вам прекрасное окно для добавления еще большего количества незапланированного кода в дальнейшем.
Других решений пока нет …