Методи в класс

djman каза:
Ако не ще, трябва да чете за ООП още :D
Аз продължавам да чета, проблема е друг. Защо и каква е логиката да накарам човек да подава обект когато подавам само стринга и го създавам. Къде е логиката да създава обекта в началото на кода примерно:

$obj = new \system\database\MySQLi($cnf['host'],$cnf['user'],$cnf['pass'],$dbname);

$AppKernel->getConnection($obj);

и да ми върне същият обект? Моята цел е по дефаулт да връща винаги инстанцията на PDO класът и ако някой желае да ползва MySQLi само да подаде като стринг името на класът с неймспейса и да се създаде обект като се избегне потребителя да прави конекция с конфигурацията да въвежда параметрите на класът и така нататък. Мисля, че един колега преди време каза, че това е по шаблона Фабрика. Не е логично да подавам и да си връщам обекта а искам да го създам. По принцип би трябвало да има сетер но това е друга тема и май ще направя такъв, но реално не мисля, че ми е много наложащ излишен код е когато и с този тип го създавам и просто му казвам кой обект да върне.
 
Твоето не е съвсем фабрика. Защо да подавам като стринг клас, а не да го създам? Фабрика би било, ако пиша pdo_mysql, mysqli, и тн. и ти според този стринг връщаш съответния обект.

Също така грешката е там, че ти не знаеш какви методи ще има новият клас. Или това е feature?
 
djman каза:
Твоето не е съвсем фабрика. Защо да подавам като стринг клас, а не да го създам? Фабрика би било, ако пиша pdo_mysql, mysqli, и тн. и ти според този стринг връщаш съответния обект.

Също така грешката е там, че ти не знаеш какви методи ще има новият клас. Или това е feature?
Напротив затова има интерфейс. Създал съм два класа с общи методи и функции. Описъл съм ги в интерфейса и когато фрейма извика какъвто и да е клас имплементирал този интерфейс то те ще са вътре. Отделно потребителя може да си добавя колкото си поиска методи в него и да си ги вика в моделите колкото и когато поиска. Не е ли по-добре само да подадеш стринга и вече да се правят проверките за конекциите в кернела на приложението като се прави инстанция към него. Тези методи са в него и от него всички класове дърпат конекцията. Явно ще трябва да направя сетер а гетера просто да си взима инфото от $this->_dbConnection;
 
AppKernel
PHP:
public function setConnection($class='\system\database\PDO',$dbname=null){
		$this->implementsInteface('system\interfaces\iDatabase',$class);
		if(empty($this->_dbConnection)){
			$cnf = $this->getConfiguration()->load('database/connection');
			if(empty($dbname)){
				$dbname = $cnf['name'];
			}
			$this->_dbConnection = new $class($cnf['host'],$cnf['user'],$cnf['pass'],$dbname);
		}
		return $this;
	}
	
	public function getConnection(){
		if(empty($this->_dbConnection)){
			$this->setConnection();
		}
		return $this->_dbConnection;
	}
Така се разпределя по класовете:
Database
PHP:
trait Database{
    private $db = null; 
	
	public function setConnection($class,$dbname){
		\system\core\AppKernel::getInstance()->setConnection($class,$dbname);
	}
	
	public function getConnection(){
		return $this->db = \system\core\AppKernel::getInstance()->getConnection();
	}
}
 
Човек, архитектурата ти е или много сложна, или много грешна, или и двете...
 
djman каза:
Човек, архитектурата ти е или много сложна, или много грешна, или и двете...

Изобщо не смятам, че е сложна. Веднага давам пример.
Този клас е напълно равносилен на
PHP:
class Test{
	use \system\traits\Database;
	
	public function __construct(){
		print_r($this->getConnection());
	}
}
ето този като разликата е че първият има централизирано ядро и просто си използвам методите.
PHP:
class Test{
	private $db = null;
	
	public function __construct(){
		print_r($this->getConnection());
	} 
	
	public function setConnection($class,$dbname){
		\system\core\AppKernel::getInstance()->setConnection($class,$dbname);
	}
	
	public function getConnection(){
		return $this->db = \system\core\AppKernel::getInstance()->getConnection();
	}
}

Не е нужно навсякъде да пиша едни и същи методи просто когато ги променя веднъж се променят напълно навсякъде в приложението. Прави се конекция към главният клас който коли и беси, и от там нататък се ползва информацията. Не мисля, че това е сложно.
 
Защо клас Test трябва да има get/setConnection? Защо изобщо трябва да знае за бази данни?
 
djman каза:
Защо клас Test трябва да има get/setConnection? Защо изобщо трябва да знае за бази данни?
Колега, това е просто пример, който съм драснал набързо в нотепад. Защо се хващаш за глупости? Дадох ти просто пример как се разпределя конекцията към базата. Не са ми нужни контейнер за инстанциите да товари паметта когато реално имам вече конекциите в главен класс и само си ги викам. :-)
 
Глупости? Опитвам се да ти кажа че това, което правиш е грешно, а ти - глупости. Еми ок. Знаеш ли кое ще товари най-малко паметта? Да няма приложение изобщо. Иначе казано: контейнер не товари; ще подобри системата значително.

Тоест класове, които изобщо не трябва да имат гет/сетКонекшън, ще го имат. Глупости индиид...
 
djman каза:
Глупости? Опитвам се да ти кажа че това, което правиш е грешно, а ти - глупости. Еми ок. Знаеш ли кое ще товари най-малко паметта? Да няма приложение изобщо. Иначе казано: контейнер не товари; ще подобри системата значително.

Тоест класове, които изобщо не трябва да имат гет/сетКонекшън, ще го имат. Глупости индиид...
Аз съм на принципа, че човек трябва да ползва това което му трябва не да бъка всичко накуп и да си избира. За какво ми е да правя инстанции на класовете и да ги бъкам в контейнер и после от там да ги взимам? В много от файловете не ми е нужно нищо по-различно от една конфигурация. Просто си слагам trait-а и съм готов. Викам си метода връща ми резултата. На мен контейнера не ми е потребен просто защото при мен инстанциите важните преминават през ядрото и от там с иги управлявам. По твоята логика за да ползвам контейнер и от там да изваждам базата аз трябва да и направя инстанция и да се конектна с нея. Проблема ми е следния, кажи ми една причина логическа аз на потребителя да правя конекция към базата без да му трябва ако сайта му е само някакви калкулатори примерно без да му трябва база? Затова точно си ползвам ядрото то ми е като контролер за тези неща и правя заявки към него, кое пък ми връща резултат. Защо трябва да създавам отделен клас в който ще държа две три инстанции и нищо повече. Използвам си просто едни трейтове вместо абстрактни класове и съм бомба. Така всичко е отделно и четимо, като се знае класът какво ползва. Давам ти веднага пример:
PHP:
class UserConnect{
	use \system\traits\Singleton;
	use \system\traits\Configuration;
	use \system\traits\Database
}
Тук знам какво ще използва класът и веднага разбирам, че е сингълтон, че има нужда от ковфигурация и че ще прави нещо с базата. Докато тук знам, че просто наследява класът и това е:
PHP:
class UserConnect extends Container{
	
}
Или пък се ползва някакъв естествано абстрактен клас който пък да прави конекция към контейнера и общо взето стигаме до аналогична ситуация с моят код. Просто при мен контейнера на този етап е само за 3 инстанциии от които две не е всеки път са наложаи в даден клас. А кажи ми сега как мислиш ти? За какво ми хвалиш нещо на което съм направил аналог без да си товара системата да правя излишни конекции към него? Затова ми е AppKernel да проверява по условия какво става да е главната конекция и това е просто. Защо трябва да създавам контейнер като имам класс който се грижи точно за това, да проверява за конфигурация, да въвежда лоадъра да и да чака в готовност да осъществи връзка с базата ако е наложаща. Отделно изгледа да предава? Той е първата и последната точка на вход и изход за потребителя. Тоест зад него се намира цялата система, той определя кой е главният контролер от там нататък имамного други фактори, но защо трябва да обяснявам когато не си виждал системата която имам. Да и да направя контейнер вместо директно към AppKernel да се обръщам ще се обръщам към контейнера а от там той към него и за какво ми е посредник като директно мога да се обърна към шефа?
 

Back
Горе