Я видел некоторые проекты, в которых классы имеют методы get и set для управления данными вставки. Позвольте мне привести пример:
class Student extends dbClass { private $TableID; private $FullName; private $Gender; private $Address; function setTableID($Value) { $this->TableID = $Value; } function getTableID() { return $this->TableID; } function setFullName($Value) { $this->FullName = $Value; } function getFullName() { return $this->FullName; } function setGender($Value) { $this->Gender = $Value; } function getGender() { return $this->Gender; } function setAddress($Value) { $this->Address = $Value; } function getAddress() { return $this->Address; } function UpdateStudent() { $sql = "UPDATE INTO usertable SET FullName = '".$this->getFullName()."', Gender = '".$this->getGender()."', Address = '".$this->getAddress()."' where TableID='".$this->getTableID()."'"; $this->query($sql); } }
Выше приведен пример класса, который я видел. Ниже приведен процесс их использования:
$student = new Student; $student->setTableID = 1; $student->setFullName('My Name'); $student->setGender('Male'); $student->setAddress('this is my address'); $studen->UpdateStudent();
-$student = new Student; $student->setTableID = 1; $student->setFullName('My Name'); $student->setGender('Male'); $student->setAddress('this is my address'); $studen->UpdateStudent();
Стоит ли так делать? Я лично считаю, что бесполезно устанавливать поле, а затем получать и обновлять записи. Это действительно занимает много времени, чтобы сделать это для каждого модуля. Каков наилучший способ справиться с такой вещью? Существует ли какая-либо безопасность в этом отношении?
Стоит ли так делать?
Это зависит.
Абстрагирование поля от пользователя путем воздействия на «умное» свойство (т.е. геттер и / или сеттер) имеет два недостатка:
И это имеет одно преимущество:
Если это преимущество имеет смысл (например, вы пишете многократно используемую библиотеку программного обеспечения), тогда имеет смысл писать свойства вместо голых полей. Если нет, вы делаете работу без пользы.
Каков наилучший способ справиться с такой вещью?
Вы можете переопределить магические функции __get
и __set
(возможно, в базовом классе, чтобы вы могли наследовать переопределение), чтобы автоматически перенаправлять доступ к свойствам вашим получателям и сеттерам. Упрощенный код:
public function __get($name) { $getter = 'get'.$name; if (method_exists($this, $getter)) { return $this->$getter(); } $message = sprintf('Class "%1$s" does not have a property named "%2$s" or a method named "%3$s".', get_class($this), $name, $getter); throw new \OutOfRangeException($message); } public function __set($name, $value) { $setter = 'set'.$name; if (method_exists($this, $setter)) { return $this->$setter($value); } $getter = 'get'.$name; if (method_exists($this, $getter)) { $message = sprintf('Implicit property "%2$s" of class "%1$s" cannot be set because it is read-only.', get_class($this), $name); } else { $message = sprintf('Class "%1$s" does not have a property named "%2$s" or a method named "%3$s".', get_class($this), $name, $setter); } throw new \OutOfRangeException($message); }
Предостережение emptor: Поскольку __get
и __set
переопределены, __isset
и __unset
должны быть переопределены!
Существует ли какая-либо безопасность в этом отношении?
Нет, нет вообще (если вы не вставляете ошибки случайно).
В языках, не имеющих свойств (public member «переменные», которые фактически приводят к вызовам функций) с использованием getter / seters вместо общедоступных переменных, обычно рекомендуется. В противном случае вы не сможете добавить логику (например, при настройке переменной) позже, если люди уже используют ваше простое поле.
Поскольку PHP – такой язык (к сожалению), ответ да, используйте их .
Создание сеттеров и геттеров помогает обеспечить инкапсуляцию ООП. Я не уверен в PHP, но для многих других языков (Java, C ++) хорошая среда IDE (eclipse / netbeans) автоматически сгенерирует эти сеттеры и геттеры для вас.
Это может быть не сразу очевидным для простых типов, но если необходимо выполнить какую-либо более сложную обработку, это становится более очевидным.