OOP - Въпроси , проблеми , отговори
- Автор index
- Начална дата
Та за абстракния class има смисал
ако работиш голям проект, защото както знаем за разлика от java или python, кодовете на php може да се напишат по различни начини, Та затова се прявят interface за да се придържа някакав стил. Имах един програмист който си правеше по 100 coonection към дб-то преди да обработи ифнотмацията.
демек
$a = new db();
$b = new db();
$c = new db();
......
ако направиш class config(примерно) и db абстракт до някъде ще и защитиш. След това singleton и т.н
ако работиш голям проект, защото както знаем за разлика от java или python, кодовете на php може да се напишат по различни начини, Та затова се прявят interface за да се придържа някакав стил. Имах един програмист който си правеше по 100 coonection към дб-то преди да обработи ифнотмацията.
демек
$a = new db();
$b = new db();
$c = new db();
......
ако направиш class config(примерно) и db абстракт до някъде ще и защитиш. След това singleton и т.н
StormBreaker
Registered
Jorko каза:
Моя съвет е да не се хвърляш директно на singleton. Научи първо идеята зад ООП, наследяване, полиморфизъм, енкапсулация и т.н. Сингълтона е просто един модел, който като разбереш ООП истински ще ти стане ясно къде може да ти е полезен и къде не и защо се използва.
Да си призная аз лично не съм много привърженик на тия сингълтони. Казвате за връзката с БД. Ама на мен ще ми е по-добре да си направя класа за БД по нормалния начин и да имам в друг клас статични (примерно) променливи за връзката. Така ако ми потрябват 2 връзки към 2 бази от данни едновременно лесно мога да си направя нова променлива в класа, който ще ми пази връзките и ще си ги ползвам. Ако класа за връзка към БД ми е сингълтон това няма да стане.
Пример:
PHP:
<?php
class Database
{
[...]
}
class Connections
{
private static $mainDb = null;
public function getMain()
{
if (!self::$mainDb)
self::$mainDb = new Database(...);
return self::$mainDb;
}
}
// Нейде в кода
$db = Connections::getMain();
$db->query(...); // и т.н.А ако ползвам Dependency injection е още по-добре. Тогава дори $mainDb няма да има нужда да е статична и да ги викам така директно чрез класа.
Общо взето всичко се свежда до едно design patterns. Трябва да структурирате така кода, че всички който рабитиш да го разбират.
Аз какво правя. Забравянвам всякакав достъп до config object-
имам един Registry object
забравявам controller с controller да си взаймодействат.
Забранявам всичко що е функция към дб-то да излиза извън модела(все пак модела е за това).
абстрактен клас това си е обикновен клас но на него не може да се направи инстанция.
Пример
abstract class DB(){
function c(){}
}
$db = new DB # ще throw грешка, че не може да се прави инстанция на класа
но ако имаш
class foo extends DB{
,.....
}
class foo вече има достъп до методите на класа
и т.н
една от големите грешки на начинаещите е да направи така
class cla extends DB{}
$d = new cla();
това е голяма грешка!!!!!
Смисъл да направи един празен class само за да има инстанция до abstract class-a
Аз какво правя. Забравянвам всякакав достъп до config object-
имам един Registry object
забравявам controller с controller да си взаймодействат.
Забранявам всичко що е функция към дб-то да излиза извън модела(все пак модела е за това).
абстрактен клас това си е обикновен клас но на него не може да се направи инстанция.
Пример
abstract class DB(){
function c(){}
}
$db = new DB # ще throw грешка, че не може да се прави инстанция на класа
но ако имаш
class foo extends DB{
,.....
}
class foo вече има достъп до методите на класа
и т.н
една от големите грешки на начинаещите е да направи така
class cla extends DB{}
$d = new cla();
това е голяма грешка!!!!!
Смисъл да направи един празен class само за да има инстанция до abstract class-a
StormBreaker
Registered
macmen каза:
Хаха то това може ли в PHP
Доста тъпо ми се струва. Реално един абстрактен клас трябва да има поне един абстрактен метод - иначе класа няма да е абстрактен.Липсата на опит води до трагични случай.Същото и в математиакта, като нямаш познания , и 2 часа да седиш на тази задача, няма да измислиш нова математика...macmen каза:Повярвай ми какво ли не съм виждал, затова пиша interface че да се сещат
И все пак , твоят начин ми изглежда доста странно.
Странен е,но върши доста работа. Караш ги да пишат заявки само в модела а не да ги разхвърля наляво надясно. Е той ако иска може да го плосне където си иска реално.
Много е важно какъв е проекта, ако е някой малък и ти си единствен програмист, то няма нужда от усложнения толкова, но ако е голям и са намесети git и т.н, то тогава трябва да се помисли в началото, че след това стават едни workaround-и
Много е важно какъв е проекта, ако е някой малък и ти си единствен програмист, то няма нужда от усложнения толкова, но ако е голям и са намесети git и т.н, то тогава трябва да се помисли в началото, че след това стават едни workaround-и
StormBreaker
Registered
macmen каза:
Ако работиш с някой, който слага заявки в контролера просто няма смисъл от този човек. В това отношение колкото и ограничения да му слагаш все ще бълва некачествен код.
macmen каза:
PHP:
class DB {
private $connection = null;
private function __construct() {}
public static function connect() {
if(self::$connection == null) {
self::$connection = new PDO();
}
return self::$connection;
}
private function __clone() {}
}
PHP:
class Model {
$db = null;
public function __construct(Cont $db) {
$this->db = $db->db;
}
/** Razni metodi */
}
PHP:
class UsersModel extends Model {
/** Razni metodi, koito veche shte imat vruzka sus PDO */
}Сега връзката за базата данни към Model.php се прехвърля през един container
PHP:
class Cont {
public function db() {
return DB::Connect();
}
}
$Model = new Model(new Cont());
/** Durji i classa model */
$UsersModel = new UsersModel();Сега на класа DB, може и да му махнем singleton а, защото ние ще го зареждаме само 1 път във Model клас, където от там го присвояваме на едно свойство и си боравим със това свойство. Тъй като UsersModel наследява Model, връзката към базата данни се наследява също.
Сега връзката е предаваме чрез класа Cont {}, който играе ролята на DiC, той ни връща инстанция и е предава на Model, но може да се преправи да ни връща директно връзката и от там да е вкараме към клас Model, който вече ще е взима ето така:
PHP:
public function __construct($db) {
$this->db = $db;
}DiC може да се направи и по още варианти, зависи просто как ще си структурираш кода.
А може изобщо да не се ползва DiC ами директно DI:
PHP:
$Model = new Model(DB::Connect());Да така също е възможно, но представете си след време класовете нарастнат, изискват повече параметри, повече класове трябва да се заредят и всичко става каша. Тогава идва DiC, тъй като единствено трябва да вкараме new Cont(), във класовете и от там ще си взимат необходимата информация.
А също DiC може да се направи singleton и когато зареждаш разни класове през DiC, тогава никой клас няма да има нужда от SingleTon и тестването на класа ще се улесни.
------------------------------------------------
Може и bulider да си направиш:
PHP:
class Builder {
public static function Build($Class, $ToWork) {
new $Class(new $ToWork);
}
}
Builder::Build('Model', 'DB');Тоест казваме искам на модел да му вкараме обекта на класа DB
----------------
Извинявам се за повторния пост, но ето как аз бих направил нещата:
Има само един singleton шаблон и той е във Container {}
Има само един singleton шаблон и той е във Container {}
PHP:
<?php
class DB {
public function Connect() {
return 'MY PDO CONNECTION';
}
}
class Model {
protected $db = null;
protected $security = null;
public function __construct($objects) {
$this->db = $objects['DB'];
$this->security = $objects['Security'];
/** Testing */
echo $this->db->Connect();
echo '<br />';
echo $this->security->hash('stest');
/** End of testing */
}
public function IsUser($user, $password) {
return $password = $this->security->hash($password);
}
/** Some basic methods for model class */
}
class Users extends Model {
/** The UsersModel methods */
}
class Security {
public function hash($value) {
return md5($value);
}
}
class Builder {
/** Define for every class with, who will work */
private static $data = array(
'Model' => array('Security', 'DB')
);
public static function Build($param) {
$objects = Container::Inject(self::$data[$param]);
return new $param($objects);
}
}
class Container {
private static $objects = array();
private function __construct() {}
public static function Inject($data) {
if(count($data) > 0) {
foreach($data as $method) {
if(!array_key_exists($method, self::$objects)){
self::$objects[$method] = self::$method();
}
}
}
return self::$objects;
}
private static function Security() {
return new Security();
}
private static function DB() {
return new DB();
}
private function __clone() {}
}
/** Creating the Model Class */
Builder::Build('Model');
?>
Код:
class Security {
public function hash($value) {
return md5($value);
}
}Нека и аз да кажа нещо, спазвайте KISS - Keep It Simple Stupid.Ако нещо може да се направи лесно и просто, не се опитвайте да го правите по сложно.Все пак си оставяйте вратичка, ако се наложи ъпгрейд на модула/сайта който правите.
Нека да спомена и за сингълтона.Преди да почнете да го ползвате е хубаво да си изясните каква ви е базата, и как се ползва Connection Pool-a към нея.Не винаги е полезен, за PHP доста често е удачен подари самия lifetime на скрипответе.Пробвайте примерно да го ползвате за връзка с базата в ASP.NET, сайта ви ще забие при повече от един потребител.
Що пък да няма заявки в конролера? Ако искам scalar value, да взема да пиша функция за всяка стойност ли?
А за това че винаги може да се пише лайнян код, е така ако ще на Assembler да пише пак може кода да заеме достойно място
тук.
http://govnokod.ru
Приятна вечер
StormBreaker
Registered
FFDP каза:Хората гледат, да не пишат по принцип излишен код, но ти освен че правиш функция, я добавяш и към клас.Код:class Security { public function hash($value) { return md5($value); } }
Нека и аз да кажа нещо, спазвайте KISS - Keep It Simple Stupid.Ако нещо може да се направи лесно и просто, не се опитвайте да го правите по сложно.Все пак си оставяйте вратичка, ако се наложи ъпгрейд на модула/сайта който правите.
Нека да спомена и за сингълтона.Преди да почнете да го ползвате е хубаво да си изясните каква ви е базата, и как се ползва Connection Pool-a към нея.Не винаги е полезен, за PHP доста често е удачен подари самия lifetime на скрипответе.Пробвайте примерно да го ползвате за връзка с базата в ASP.NET, сайта ви ще забие при повече от един потребител.
Що пък да няма заявки в конролера? Ако искам scalar value, да взема да пиша функция за всяка стойност ли?
А за това че винаги може да се пише лайнян код, е така ако ще на Assembler да пише пак може кода да заеме достойно място
тук.
http://govnokod.ru
Приятна вечер
Не разбрах нищо от това, което написа. Какво общо има кода, който си пуснал в началото с текста?
Singleton и за PHP не е много удачен по простата причина, че може да искаш да работиш с повече от една БД едновременно. Все някога ще ти се наложи, и когато това стане ще трябва да променяш доооооста код.
Какво разбираш под scalar value и защо ще искаш да правиш заявка в контролера? Дай примерен случай, в който според теб трябва да има заявка в контролера.
Какъв е тоя сайт?
Обектно-ориентираното програмиране (ООП) е парадигма в компютърното програмиране, при която една програмна система се моделира като набор от обекти, които взаимодействат помежду си, за разлика от традиционното виждане, в което една програма е списък от инструкции, които компютърът изпълнява. Всеки обект е способен да получава съобщения, обработва данни и праща съобщения на други обекти.strasburg каза:
Твърди се, че обектно-ориентираното програмиране дава повече гъвкавост, като прави по-лесно променянето на програми. То намира широка популярност в софтуерното инженерство на мащабни проекти. Поддръжниците на ООП заявяват, че ООП е по-лесно за учене от начинаещи програмисти, за разлика от по-ранни подходи и методики, както и че ООП подходът често е по-прост за разработване и поддържане.
strasburg каза:
Така strasburg, Index ти обясни какво е ООП, а аз ще ти кажа защо е по добре да пишеш даден сайт на ООП.
Първо като цяло се трърди, че ООП PHP има по-добър Performance от процедурния, второ при ООП като напишеш даден клас може си го викнеш 20 пъти в 10,20,30,40 станици докато при процедурнито на всяка страница пишеш различен код един вид класовете в ооп са като функцийте в процедурното писане
..Дано си разбрал че и аз се оплетох малко
:!: :?: