Объявление классов

Вот классический пример. Совсем запутали, кому что надо. Это для ТС подходит.
PHP:
<?php

//интерфейс (необязателен, поэтому в пхп4 можно не объявлять
interface ITest{
	
	function test();
}

//один вариант класса.
class A implements ITest{
	
	function test(){
		return "A";
	}

}

//другой вариант класса
class B implements ITest{
	
	function test(){
		return "B";
	}

}

class Client{
	
	private $_ab;
	
	function __construct(ITest $ab){
		$this->_ab=$ab;
	}
	
	function run(){
		echo $this->_ab->test();
	}
}

//А и В снаружи совершенно идентичны

//создание по условию какому нибудь

//условие. Может быть задано в коде, в конфиге, динамически и так далее.
$class=1;
//$class=2;
$ab=($class==1)?new A():new B();

//использование
//код не меняется даже если создать еще море классов C, D, E ...
$client=new Client($ab);
$client->run();

в пхп поддерживается Duck Typing поэтому явное указание интерфейса не обязательно, но явное указание как бы тру путь, чтобы не пропихивали то, что не подходит.

если же вам нужно создать класс, а потом программным путем изменить в нем поведение метода - то этого походу сделать нельзя ... а если и можно - то не желательно делать, так как такое поведение типа "не в стиле ооп" и усложнит дальнейшее понимание кода
Можно и очень даже в стиле ООП.
1)Обычная обертка (Декоратор).
2)Наследование с переопределением этого метода.
3)Изменение функциональности метод на лету - стратегии.
 
в пхп поддерживается Duck Typing поэтому явное указание интерфейса не обязательно, но явное указание как бы тру путь, чтобы не пропихивали то, что не подходит.
Можно и очень даже в стиле ООП.
1)Обычная обертка (Декоратор).
2)Наследование с переопределением этого метода.
3)Изменение функциональности метод на лету - стратегии.

Я опять у вас код попрошу. Это как раз по моему вопросу если я правильно понял.
 
Я опять у вас код попрошу. Это как раз по моему вопросу если я правильно понял.
В вашем случае просто наследование с переопределением нужного метода. Пример уже давали.
Декоратор нужен, когда надо расширить функциональность метода (что то добавить незаметно для клиента). Конечно, можно то же самое и наследованием, просто декораторы проще переиспользовать.
Если у класса Client run переименовать в test - то вот вам подобие декоратора.

Стратегия - тот код, что я дал будет стратегией если добавить в класс Client
PHP:
function setStrategy($ab){
   $this->_ab=$ab;
}
что даст возможность менять экземпляры у класса Client при работе когда угодно.
зы: И прежде чем вас унесет в дебри паттернов и прочей ерунды хочу сразу предупредить и спасти от будущего аналитического паралича и чтения многих холиваров. Это ошибка многих программистов, ищущих идеальное решение. Все эти паттерны имеют очень смазанные границы между собой, так что название подходит скорее для коммуникации. Многие их применяют, даже не зная, что оно вообще такое. Не надо пытаться сделать все по паттерну, а надо делать так, как удобнее всего в данной ситуации. Паттерны - как векторы построения дизайна. Реализовывать их надо ровно настолько, пока решение не заработает. И остановиться. Пусть даже там до классических примеров далеко.
 
В вашем случае просто наследование с переопределением нужного метода. Пример уже давали.
Декоратор нужен, когда надо расширить функциональность метода (что то добавить незаметно для клиента). Конечно, можно то же самое и наследованием, просто декораторы проще переиспользовать.
Если у класса Client run переименовать в test - то вот вам подобие декоратора.
Стратегия - тот код, что я дал будет стратегией если добавить в класс Client
PHP:
function setStrategy($ab){
   $this->_ab=$ab;
}
что даст возможность менять экземпляры у класса Client при работе когда угодно.
зы: И прежде чем вас унесет в дебри паттернов и прочей ерунды хочу сразу предупредить и спасти от будущего аналитического паралича и чтения многих холиваров. Это ошибка многих программистов, ищущих идеальное решение. Все эти паттерны имеют очень смазанные границы между собой, так что название подходит скорее для коммуникации. Многие их применяют, даже не зная, что оно вообще такое. Не надо пытаться сделать все по паттерну, а надо делать так, как удобнее всего в данной ситуации. Паттерны - как векторы построения дизайна. Реализовывать их надо ровно настолько, пока решение не заработает. И остановиться. Пусть даже там до классических примеров далеко.

Нет, не унесет. Я как правило ищу рабочие решения. На прошлой неделе столкнулся с необходимостью заставить одну функцию из класса работать по-другому, так день убил пока разобрался в куче сопутствующего материала который вопроса только краем касался.

Теперь буду иметь шпаргалку. Спасибо вам за помощь!
 
заставить одну функцию из класса работать по-другому
А просто породить новый класс и переопределить функцию не помогает?
 
А просто породить новый класс и переопределить функцию не помогает?

Врядли. В моем случае речь шла о виджетах вордпресс, в один из которых нужно было добавить дополнительные данные.
Если я правильно понимаю нужно было создать класс с таким же именем, т.е. тот нужно деинициализировать. На уровне темплейта через функции не уверен что это правильно. Гораздо лучше в классе заменить одну функцию на другую и все.
 
Назад
Сверху