ZSH

Ну что же, видимо на этом форуме мне уже делать нечего.... буду просить помощи в другом месте....

всякая практика лучше любой теории.
Стандартный "школьный" образец:

abstract class User{
 
	function __construct($name){
	$this->name = $name;
	}
 
	function getName(){
	return $this->name;
	}
 
	// Permission methods
	function hasReadPermission(){
	return true;
	}
 
	function hasModifyPermission(){
	return false;
	}
 
	function hasDeletePermission(){
	return false;
	}
 
	// Customization methods
	function wantsFlashInterface(){
	return true;
	}
 
	protected $name = NULL;
}
 
class GuestUser extends User {
}
 
class CustomerUser extends User {
	function hasModifyPermission(){
	return true;
	}
}
 
class AdminUser extends User {
	function hasModifyPermission(){
	return true;
	}
 
	function hasDeletePermission(){
	return true;
	}
 
	function wantsFlashInterface(){
	return false;
	}
}
 
class UserFactory {
	private static $users = array("Andi"=>"admin", "Stig"=>"guest", "Derick"=>"customer");
 
	static function Create($name){
		if(!isset(self::$users[$name])){
		// Error out because the user doesn't exist
		}
		switch(self::$users[$name]){
		case "guest": return new GuestUser($name);
		case "customer": return new CustomerUser($name);
		case "admin": return new AdminUser($name);
		default: // Error out because the user kind doesn't exist
		}
	}
}
 
function boolToStr($b){
	if($b == true){
	return "Yes\n";
	}
	else{
	return "No\n";
	}
}
 
function displayPermissions(User $obj){
	print $obj->getName()."'s permissions:\n";
	print "Read: ".boolToStr($obj->hasReadPermission());
	print "Modify: ".boolToStr($obj->hasModifyPermission());
	print "Delete: ".boolToStr($obj->hasDeletePermission());
}
function displayRequirements(User $obj){
	if ($obj->wantsFlashInterface()) {
	print $obj->getName()." requires Flash\n";
	}
}
 
$logins = array("Andi", "Stig", "Derick");
 
foreach($logins as $login){
	displayPermissions(UserFactory::Create($login));
	displayRequirements(UserFactory::Create($login));
}

Ice Посмотрю.

@ice если он с примерами и кодом не все понял, то просто одним кодом ему не помочь

//тут я должен выдать object типа bmw
$bmw=Фабрикамашин::факториМетод("bmw");

//a тут object типа запарожец
$zapor=Фабрикамашин::факториМетод("таврия");

SlavaFr Мы можем запросить запор, а получить BMW, в жизни бы так.

вон самый простой пример с машинками:

class Bmw{

	private $price = 999;
	
	public function getPrice(){
		return $this->price;
	}
}

class Zapor{

	private $price = 111;
	
	public function getPrice(){
		return $this->price;
	}
}

class CarFactory{
	
	public static function getCarInstance($carName){
		if($carName = 'bmw'){
			return new bmw();
		}
		if($carName = 'zapor'){
			return new zapor();
		}	
	}
}

и результат:

echo CarFactory::getCarInstance('bmw')->getPrice(); // 999

разве не упрощает жизнь?

во, Mizka тоже правильный пример привел который блогодаря наплевательскому отношению php к типам прекрассно подходит. Изменив этот пример мы можем и к вопросу "Нафига" подойти и одновременно увидеть как это в других языках программирования работает.

в программе нам в конечном итоге надо с таваром работать.
товар->getPrice(); это то, что мы хотим применять на все объекты которые нам выдает Фабрика во время протикания программы.
Чтобы мы завтра могли работать с бубликами, то надо, чтоб и бублики имели метод getPrice. Чтоб навязать всем товарам этот метод самым ефективным способом это зделать интерфейс

interface iTovar
{
    public function getPrice();   
    public function __constrict();//чтоб контруктор был без параметров
}

и зделать из машин товар посредством того что мы допишем
implements iTovar

error_reporting(E_ALL);
/**
* условие для использования в нашей программе
* ваш класс должен переписать интерфасе iTovar
*/
interface iTovar
{
     /* @return float */
    public function getPrice();   
    public function __construct();//чтоб контруктор был без параметров
}

###### классы пременяемые в фабрике #######
class Bmw implements iTovar{
    private $price = 999;
	
	public function __construct(){}
		
	public function getPrice(){
		return $this->price;
	}
}

class Zapor implements iTovar{
	private $price = 111;
	
 	public function __construct(){}
		
	public function getPrice(){
		return $this->price;
	}
}
#############################

###### Фабрика машин
class CarFactory{
	
	public static function getCarInstance($carName){
		if($carName = 'bmw'){
			return new bmw();
		}
		if($carName = 'zapor'){
			return new zapor();
		}	
	}
}



###############Фабрика Tovar ###############

/**
 * Class TovarFactory 
 */
class TovarFactory{
	/**
	 * 
	 * Фабрика для выдачи товара
	 * @param $tovar : string 
	 * @return iTovar
	 */
	public static function FactoryMethod_getTovar($tovar){
		$tov=new $tovar;
		if(is_a($tov,'iTovar'))return $tov;
		//
		$tow=null;
		throw new Exception("а $tovar не товар!!!", 1);
	}
}

##########Применение гдето в программе
$tovarmasiv=array('Bmw','DomDocument','Zapor');
foreach($tovarmasiv as $tovar_nazvanie){
	try {
	
		$t=TovarFactory::FactoryMethod_getTovar($tovar_nazvanie);
		echo $tovar_nazvanie.':'.$t->getPrice().'<br />';	
		} catch (Exception $e) {
			echo $e->getMessage();
		}
}		
exit;

Становится ясным, что Фабрика является надежным методом чтобы создовать объекты одного типа но разных классов. Посредством этой техники можно использовать в программе $t->getPrice не зависемо от того яцляется $т запорожцем или bmw и одновременно наязать другим в пренудительном виде программировать мной навязаные методы.
Фабрика часто используется в программировании plugin.

И так, буду бить по рукам больно.

abstract class User {}

Нет никакой необходимости в абстрактном классе.
Конструкции вида

function displayPermissions(User $obj) {}

принимают объекты класса User, но !!не!! GuestUser или AdminUser и прочих унаследованных классов от User. Конструкции вида

public static function getCarInstance($carName){
    if($carName = 'bmw'){
        return new bmw();
    }
    if($carName = 'zapor'){
        return new zapor();
    }	
}

жутко ограниченные.

if(is_a($tov,'iTovar') {}

заменить на

if ($tov instanceof iTovar) {}

Но суть вообще не в этом, зачем создавать экземпляр класса, чтобы потом в случае ложного условия сделать ему unset()

public static function FactoryMethod_getTovar($tovar){
    if($tov == 'iTovar'))
    {
        $tov = new $tovar;
        return $tov;
    }
    throw new Exception("а $tovar не товар!!!", 1);
}

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

я применил в моем случае специально is_a вместо instanceof так как iTovar является интерфейсом, а оператора implementsof eще не придумали.

Mizka
1. Потому что абстракция не для этого, в данном случае достаточно просто написать

class User {}

2. Потому что достаточно взять и накидать данный код и попробовать исполнить, получится ошибка аля

Catchable fatal error: Argument 1 passed to ... must be an instance of User, instance of TAdmUser given ...

3. Даже примеры должны быть корректными.
4. То что было деприкейт, не факт, что таковым не станет таковым снова. instanceof более корректна.
5. Ну может не все, но большинство и плюс также теряется весь кайф в ООП.

SlavaFr
Не важно, instanceof работает и для интерфейсов. Можно было и через абстракцию

abstract class aTovar
{
    abstract public function getPrice();   
    abstract public function __construct();
}

Может проще сказать фабричному методу что нужно создать, тогда количество вариантов уходит в бесконечность?

Ice

class TCore
{
    ...
    public function apiCreateObject($ClassName, $Properties = array(), $Enveroment = null, $InStack = false)
    {
        if (!class_exists($ClassName)) die('Error : Class not exists.');
        $Object = new $ClassName($Properties);
        ...
        return $Object;
    }
}

class TObject extends TService
{
    ...
    public function __construct($Properties = array())
    {
        ...
        foreach($Properties as $PropertyName => $PropertyValue)
            $this->$PropertyName = $PropertyValue;
    }
    
    public function __set($PropertyName, $PropertyValue)
    {
        $this->Properties[$PropertyName] = $PropertyValue;
    }
    
    public function __get($PropertyName)
    {
        return isset($this->Properties[$PropertyName]) ? $this->Properties[$PropertyName] : null;
    }
}

class TUser extends TObject
{
}

$User = TCore::$Kernel->apiCreateObject('TUser', array('Login' => 'Vasya', 'Password' => '1234'));

вот это другое дело, а то сразу по рукам бить. Ишь, распоясался

@linker прокоментируй свой последний код.

SlavaFr
А что конкретно не понятно? Есть "фабрика", есть метод, ему отдается имя класса создаваемого объекта, список значений полей. Все просто.

Ну так и у других есть тоже фабрика, причем работающая. Мне не понятно что в ней особеного, что я должен из этого кода для себя подчеркнуть?

Какая дурь...

    public function apiCreateObject($ClassName, $Properties = array(), $Enveroment = null, $InStack = false)
    {
        if (!class_exists($ClassName)) die('Error : Class not exists.');
        $Object = new $ClassName($Properties);
        ...
        return $Object;
    }

использование die в классе - моветон.

структура классов у тебя честно говоря непонятная...
что за класс TService?
что за проперти $Enveroment = null, $InStack = false в конструкторе?

class TUser extends TObject
{
}

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

$User = TCore::$Kernel->apiCreateObject('TUser', array('Login' => 'Vasya', 'Password' => '1234'));

а тут интересно... оно создаст $Kernel экземпляр класса TCore? или это просто неправильное обращение к статическому методу? ну т.е что за $Kernel? да и apiCreateObject() у тебя не статический просто не встречал такой конструкции раньше

примеры должны быть тоже корректными

Да я про вообще...
Вот зачем нужен этот паттерн? По большому счету для того, чтобы как то разрулить сильную связанность кода, которая присуща исключительно ООП.
А так, как в веб приложениях связанность не просто зло, а зло абсолютное, приходится лепить на этот тришкин кафтан всякие вот такие глупости.

А потом, набрав полный рот гов умных терминов, разводить подобные дискуссии на ровном месте.

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

Да признать то несложно. Я не против, конечно так удобнее.
Однако ты не понял. Конечно, если ты сделал валидатор по такой архитектуре, он крайне неудобен. Выхода два -
1. Сделать фабрику.
2. Не делать такой архитектуры.

Первый момент подразумевает сначала сделать себе головняка, потом его разруливать с помощью заплаток, которые высокопарно назвали "шаблоны проектирования"

Второй никаких этих сложностей не имеет по определению.

Ведь большая часть паттернов призвана как то облегчить участь ООП программистов и хоть чуть чуть размотать этот клубок запутанного и связанного кода.

То есть повторюсь - сначала сами себе придумываем проблему, потом придумываем костыль, как её избежать.

значит линкёр не принял вызов?

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

Mizka
1. Понимаешь класс User содержит исключительно реализованные методы и ни одного абстрактного. Какой из этого следует вывод? Первое, абстракция не нужна; второе, интерфейсы только объявляют методы, требующие реализации; третье, достаточно просто class User {}. Никакой абстрактный класс никогда не описывает никаких структур классов.
2. PHP 5.3.0, PHP 5.3.3 - не работает, отдается ошибка или ты думаешь я по памяти написал текст этой ошибки?
5. Например наследование, полиморфизм, абстракции и прочее.

По поводу своего примера, ок, прокомментирую:
1. die() здесь сугубо моя вставка для данного поста, на самом деле в оригинале написано иначе.
2. Нужна структура?

TCore
TLdlm -> TService -> TObject -> любой иной класс

для примера реализации контейнеров

                           TMySqlServer     TCsv  TVcf
                                        \    |    /
TLdlm -> TService -> TObject -> TList -> TContainer -> TXml
                                          |        \
                                   TMySqlDatabase TMySqlTable

3. Загляни в реализацию класса TObject там написано, что за проперти.
4. $Enveroment и $InStack - к делу не относятся.
5. Класс TUser пустой потому что это пример, пустой класс вполне корректен, тем более что он наследник TObject, а значит имеет все, что имеет родитель.
6. Обрати внимание на множественные многоточия, говорящие о том, что здесь пропущен код. TCore - синглтон, экземпляр которого создается один раз.
7. TCore::$Kernel - в силу ряда причин мне нужен именно объект ядра, к которому я всегда и везде смогу обратиться без использования всяких глобальных переменных и прочих извратов.
8. Читайте доку на мой Framework и все станет понятно.

Еще примерчик в угоду twin'а, как оно удобно

$User = TCore::$Kernel->apiCreateObject('TUser', $Container->apiView("SELECT * FROM `Users` WHERE `Id` = '1'"));

abstract class Base{

	abstract function getValue();
}

class First extends Base{
	
	public function getValue(){
		echo 111;
	}
}

class Second extends Base{
	
	public function getValue(){
		echo 222;
	}
}

class Test{

	public function invoke(Base $obj){
		$obj->getValue();
	}
}

$test = new Test();
$test->invoke(new First()); //111
$test->invoke(new Second()); //222

Mizka
Должен, но не обязан. Абстракция и интерфейсы не отвечают за полиморфизм как таковой, они обязывают и гарантируют реализацию абстрактных и интерфейсных методов, соответственно. В классе User нет ни одного абстрактного метода, а следовательно нет никакой необходимости объявлять его абстрактным. Плюс, не забываем, что не было никакой необходимости что-либо реализовывать внутри класса - лень и много букв для примера. Не там вы цепляетесь за корректность.

Не работает, вот хоть тресни.