Чрезмерное использование $ this в качестве параметра объекта в PHP. Как этого избежать? - PullRequest
0 голосов
/ 07 октября 2009

Я работаю в PHP5 уже пару лет и разработал облегченную среду MVC, которую я использую для ускорения разработки сайта. Прекрасно работает, автоматизированный formbuilder, модуль autoSQL и т. Д.

Одна плохая привычка, которую я разработал, однако, полагается на $ this как на простой объектный параметр. Мне еще предстоит выяснить, как действительно инкапсулировать данные без необходимости расширяться из базового класса (где определены все переменные сайта) и с помощью метода setter заполнять каждый экземпляр объекта переданным $ this объектом. Все работает, но смешно, что каждый объект должен знать обо всем состоянии приложения. Я хотел бы, чтобы каждый объект выполнял свою назначенную задачу, требующую только минимального знания внешнего контекста.

Например, допустим, у меня есть класс, который генерирует данные учетной записи клиента:

// pseudo account

Class account extends siteBase {

protected $formObj;
public $custID = 1;
public $name;
public $email;
// etc...

 function __construct() {

  $this->formObj = new FormBuild($this); // easy $this passing

  $this->formObj->getFormData();

  $this->formObj->build();

}
}

// pseudo form builder class

Class FormBuild extends siteBase {

 protected $data;

 function __construct($caller) {

  $this->set($caller); 

 }

 function set($arr) { 

  foreach($arr as $key => $val) {

   $this->$key = $val;

  }

 }

 function getFormData() {

  $this->data = new FormQuery($this); // more easy $this passing

 }

 function build() {
  foreach($this->data as $key => $val) {
   echo $key . " " . $val . "<br>";
  }
 }
}

Class FormQuery extends siteBase {

function __construct($caller) {

  $this->set($caller); 

 }

 function query() { 

  $sql = "SELECT email, phone FROM account WHERE custID = '$this->custID'";

  // query & return return result, etc.

 }

}

Что «профи» делают это в ситуации? Я бы хотел немного почистить интерфейс ...

Ответы [ 3 ]

2 голосов
/ 07 октября 2009

Есть много подходов к этой проблеме. Вот несколько

  1. Глобальные или классовые константы
  2. Внешние данные конфигурации / статические данные (стиль INI, xml, yaml, база данных и т. Д.), Читаемые каким-либо классом конфигурации
  3. Шаблон реестра
  4. Схема впрыскивания по принципу зависимости / инверсии

У всех есть свои взлеты и падения - не существует "одного истинного решения".

0 голосов
/ 08 октября 2009

Оба ответа верны.

У меня есть встроенный контейнер объекта / свойств реестра, который я передаю соответствующим объектам, которые больше не нужно наследовать от базового класса приложения. Немного хлопот по сравнению с передачей $ this, но это улучшает планирование и заставляет меня определять, что нужно знать моим объектам, а не знать все.

Совет по рефакторингу также помог мне разобрать несколько часто используемых объектов, чтобы они выполняли только свою работу, а не несколько работ одновременно.

Тем не менее, способы еще есть, я привык знать все о приложении практически из любой точки приложения ...

0 голосов
/ 07 октября 2009

Попробуйте взглянуть на код клиента: производный класс должен иметь тот же интерфейс, что и родительский класс, но другую реализацию.

Грязный интерфейс, такой как методы в родительских классах, которые не используются в производных классах, никогда не должен существовать и был бы хорошим советом для запуска рефакторинга. Еще один сильный намек, который вы, скорее всего, заметили, заключается в том, что методы не принимают одинаковые аргументы (сравнение account::__construct() с FormBuild::__construct($caller), оба получены из siteBase::__construct()).

Я бы выполнил рефакторинг с учетом конфигурации, что если siteBase включает базу данных, но производный класс нуждается в другом / наборе разных баз данных? Попытайтесь выделить свои общие классы и посмотрите, какие из них действительно имеют общую подпись, соединяйте несколько одновременно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...