Tema za savjete za good i bad practice u PHP-u

Programiranje
1

Tema za savjete za good i bad practice u PHPu.

Uvodno pitanje, zanima me optimizacija oko loadanja skripti.
Recimo da imam neki basic.php gdje držim osnovne funkcije koje koristim.
E sad, meni jedna logika u glavi govori da taj file mora biti što sažetiji pošto se loada kod otvaranja svake stranice…druga pak logika mi govori da tu kilobajti ne igraju preveliku ulogu kao što igraju recimo kod isporučivanja sadržaja gdje svaki kb otežava load stranice.
Ta pretpostavka pretpostavlja da kad se neka skripta loada na serveru, ona se nalazi u RAM memoriji servera…odkuda je brzo dalje dohvatljiva…i šta bi tu smetao koji kb više?

No koja je najbolja praksa oko includanja skripti kako to sve radilo što efikasnije, nemam pojma. Ako netko zna nešto pametno napisati na tu temu, neka slobodno podjeli.

Također, možda mali osvrt na sljedeći tekst:
Izvor: Object-Oriented PHP for Beginners | Envato Tuts+

Another benefit of OOP is how well it lends itself to being easily packaged and cataloged. Each class can generally be kept in its own separate file, and if a uniform naming convention is used, accessing the classes is extremely simple.

Assume you’ve got an application with 150 classes that are called dynamically through a controller file at the root of your application filesystem. All 150 classes follow the naming convention class.classname.inc.php and reside in the inc folder of your application.

The controller can implement PHP’s __autoload() function to dynamically pull in only the classes it needs as they are called, rather than including all 150 in the controller file just in case or coming up with some clever way of including the files in your own code:

<?php function __autoload($class_name) { include_once 'inc/class.' . $class_name . '.inc.php'; } ?>

Having each class in a separate file also makes code more portable and easier to reuse in new applications without a bunch of copying and pasting.

Jasno mi je da je poželjno includati samo one skripte koje ćemo koristiti…no ne kužim iz gornjeg teksta zašto se pretpostavlja da je to prednost kod korištenja klasa??. Ne demantiram vrijednost klasa, samo ne kužim dali one imaju neko svojstvo koje sam propustio…jer zašto nebi mogao isto tako koristiti funkcije i includati samo skripte sa potrebnim funkcijama??

2

Jedan jednostavan odogovor, ako u 2015 godini, sa PHP verzijom 7 na pragu jos uvijek programiras prcodeuralno i skupljas funkcije naokolo sa include i require onda definitivno to radis pogresno i jedino sto ti je cinit je sjesti jos jednom u skolske klupe sastaviti se sa OO programiranjem, nauciti koje su prednosti, kako to iskoristiti u svakodnenvom zivotu i krenuti ispocetka. Takodjer u tom periodu prouciti i sta su to frameworks i koji od njih bi tebi odgovorao. Ja mislim npr. s obzirom da brijes na brzinu bi ti vrlo zanimljiv bio https://phalconphp.com/en/

I tako to…

2 Likeova
3

Jbga…ja sam danas stigao s deLoreanom, tamo kod mene još procedualno, evo jučer istjerivao neki bug…nakraju muha sama izletila iz katodnog sofisticiranog čipa i pri tome oslobodila punih 0.042 bytea nove memorije. Da mi je tvoje znanje bilo, gađao bih muhu tenkom…tako je upravo opisano forsiranje korištenje klasa na gornjem linku. Muhu gađat tenkom. Pa bemu ne znače klase da su funkcije izumrle…sve ima svoje kad i zašto.

No vratimo se na pitanje koje NIJE BILO: klase ili funkcije, nego kako pravilno raditi sa uključivanjem istih u radne filove.
Ja jesam za php prilično neuk, ali to ne znači da želim da neki framework riješi moje probleme…nego želim znati kako stvari funkcioniraju.
Ako možeš i želiš pridonjeti u tom smislu pridonesi…

4

Napravis si 1 file u koji ces sve includat klase,funckije, povezivanje s bazom.

Evo ja si ovako napravim konfig.php i u njega stavim

error_reporting(E_ALL);

session_start();

// database
$DBhost = 'localhost'; // database name
$DBuser = 'root';    // database username
$DBpass = ''; // database password
$DBname = 'test_xfire'; // database name

// connect to database
try {
$DBH = new PDO('mysql:host='.$DBhost.';dbname='.$DBname, $DBuser, $DBpass);
} catch (PDOException $e) {
die('Unable to connect to database.');
}

// include classes
include 'func/functions.php';
include 'classes/sanitize.php';
include 'classes/users.php';
include 'classes/countries.php';
include 'classes/clans.php';

// call classes
$users         = new Users($DBH);
$countries     = new Countries($DBH);
$clans         = new Clans($DBH);

I samo includam taj file gdje mi je potreban.

5

Ljudi naucite http://laravel.com/ i vas zivot ce se promjeniti, jednostavno ce procvasti!!!

2 Likeova
6

Tek sa ozbiljnijim projektima dolaze i ozbiljni problemi posebno u segmentu skalabilnosti i odrzavanja alikacije. Tu su klase neminovne. Pogledaj malo dizajn paterne i interfejse recimo.

Nedavno sam radio jedan e-commerce sajt i cijeli sistem e-placanja sam rijesio preko Factory patterna i interfejsa koji determinise implementaciju gateway-a. Rezultat toga je da “core” kod koji hendla placanje je jedan i za svaki gateway isti dok se dinamicki, zavisno od odabira nacina placanja, inkluda implementacija.

Tako da operativno imam 3 kljucne linije koda npr. nesto ovako:

$payment = Factory::init($gateway):
$payment->init();
$payment->execute();
$payment->complete();

I vrlo lako mogu napraviti novu implementaciju gateway-ja. Samo kreiram novi fajl/klasu i implementiram interfejs.

PS. Poslusajte @Dooki-ja za Laravel.

7

Ocke, samo taj dio mi je jasan.

Mene znači međuostalim zanima zašto je u kvotanom tekstu u uvodnom postu dana prednost klasama da se lakše organiziraju kod includanja?
Mislim, da je u tom tekstu svugdje umjesto “classes” pisalo “functions”, sve bi dalje isto pasalo…ili nešto nisam skužio??

Da ponovim za ovakve poput creatifcode, ne želim s ovim gore reći da ja pod sto posto moram koristiti funkcije…i da ne želim klase…nije u tome stvar uopće. Samo me zanima dali je to nespretna greška u tekstu da je to benefit klasa pred funkcijama… ili klase posjeduju neko svojstvo vezano uz includanje za koje neznam??

Drugo pitanje je bilo…
Znači ti svojim pristupom includaš svaki puta sve…(ako pretpostavimo da ne ugrađuješ neku logiku koja odlučuje što se kad includa). E sad, to je ocke do koje mjere? Kada takav pristup postaje overdoze? Što je serveru puno, a što malo?
Što točno uopće stvara težinu serveru kad ima puno toga includano?
-dali mu je teško pročitati podatke sa harda? Ako uzmemo da je učitavanje podataka sa harda relativno spor proces…dali server uopće mora includat sa harda ili povlači to iz svog RAM-a,?? (naravno, nakon što jednom povuče sa harda)
-dali mu je možda teško pak prebirati između puno klasa/funkcija? (to mi je također nevjerovatno, kad bi sve trebalo biti indeksirano)
-što je onda težina? …koji je temeljni razlog da se nešto includa a nešto ne u svrhu optimizacije?

Možda to što server mora compajlirati prvo sve skripte prije nego ih koristi?? …a više skripti pojede više resursa za kompajliranje??

8

Svakako ću se orijentirati na neki framework, ali ovo nije tema koja traži savjete toga tipa. Mislim, svejedno hvala za sugestiju…da nebi bilo zabune.

Ja bi samo volio shvatiti neke fundementalnije stvari …i eventualno nadograditi svoje znanje sa propustima koje sam ostavio također na tim fundementalnim razinama. Kad pokrpam te rupe u svom znanju…onda ću rado uzeti nešto što su napravili ljudi koji su također razumjeli fundementalne stvari :slight_smile:

1 Like
9

PHP se interpretera ne kompajlira. :wink: Mozda ti ne zvuci kao nesto bitno ali obrati paznju na to posto razlika postoji.

10

Eh…ponekad neznam ni od kuda iščupam riječ kompajler…i njeno točno značenje. A značenje interpreter još manje kužim…

Pod kompajler sam mislio obrada. Istina, kod obrade moramo imati ulaznu informaciju/sintaksu koju ćemo obraditi/kompajlirati u nekakvu izlaznu.

Pod tim sam mislio da php prvo mora znači proći svu sintaksu koju smo mu dali te ju obraditi da napravi izlaz koji će on razumjeti šta je šta…i gdje će provjeriti jeli sve napisano uopće u skladu sa PHP sintaksom…i puknut nam error ako nešto nije dobro.
E sad, ako se taj proces zove interpretacija…onda smo mislili na isto…ali odabrah krivu riječ…

11

Biti će da je ovo jedan od odgovora koje tražim:
http://php.net/manual/en/language.oop5.autoload.php

Many developers writing object-oriented applications create one PHP source file per class definition. One of the biggest annoyances is having to write a long list of needed includes at the beginning of each script (one for each class).

In PHP 5, this is no longer necessary. You may define an __autoload() function which is automatically called in case you are trying to use a class/interface which hasn’t been defined yet. By calling this function the scripting engine is given a last chance to load the class before PHP fails with an error.

12

Kako napravit laravel da radi na localhostu ? Gledam onu dokumentaciju ajme,

13
1 Like
14

Ovo radi po očekivanju:

function __autoload($class_name) 
	{
	global $Root;
	include $Root.'php/classes/'.$class_name.'.php';
	}

…dok god se file zove jednako kao klasa, i dok se ti fileovi nalaze unutar: $Root.‘php/classes’.

No, što kad poželim unutar php/classes grupirati filove po folderima, kako je onda najbolje uputiti autoloadera kuda da gleda?
Pretpostavljam da keyword use tu igra ulogu, ali ga ne kužim baš što on točno radi i koja mu je namjena…

15

Tvoj Class name je put do klase.

Recimo
class Ovo_Je_Klasa_Koja_Se_Nalazi_U_Folderu_Klase { }

ovo je struktura foldera
/Ovo
/Je
/Klasa
/Koja
/Se
/Nalazi
/U
/Folderu
/Klase

i onda

function __autoload($class_name) {
    $path = replace('_', '/', $class_name);
    include $path . '/' . $class_name . '.php';
}

Naravno ovo je najbanalniji primjer i ne treba ga koristiti u produkciji. Druga stvar, pogledaj PSR standarde http://www.php-fig.org/psr/

Itd, itd.

16

Hmm, onda naziv klase moram imati u koreleaciji sa njenim pathom :confused: …a to mi se ne čini baš najbolje.

S druge strane skužio sam ovo sa namespace-ovima i keywordom use.
Znači mogli bi kod svake klase definirati namespace:

namespace path\to\this\class;
class myClass{...}

i onda kod poziva pozivamo:

$miki=new path\to\this\class\myClass();

ili ako ne želimo pisati cijeli path, definiramo “use” :

use path\to\this\class as nesto;

//pa poziv može biti samo:
$miki = new nesto\myClass();

mogli smo i:

use path\to\this\class\myClass; 
//sto je ekvivalent pozivu:  use path\to\this\class\myClass as myClass;

//i onda poziv izgleda vrlo simple:
$miki=new myClass();
//smo mi to nema baš preveć smisla, jer onda moramo do svake klase definirati use

Kako god okreneš, kod tebe mora biti naziv klase u korelaciji sa pathom, ovdje mora biti namespace u istoj korelaciji.
Prednosti mane?
Koliko vidim, u slučaju selidbe fileova ima čačkanja po nazivima i u jednom i u drugom slučaju. Iako nešto manje čačkanja u slučaju sa namespace-om. (To se odnosi naravno samo za selidbe koje su re-razmještaj fileova unutar glavnog foldera gdje se nalaze sve klase)
Što se tiče optimizacije, vrag zna, iako mi se čini bolje ovo sa namespaceom gdje nemamo nikakav replace, te možemo direktno postaviti autoloader:

function __autoload($class_name) 
	{
	include ROOT.'php/classes/'.$class_name.'.php';
	}

Ako ima argumenata protiv namespace-a, udarajte :slight_smile:

17

Nema argumenata protiv namespace. Inace, namespace ne mora pratiti strukturu foldera uopste ali je to dobra praksa. Namespace su tu primarno kako bi se izbjegao class name konflikt na vecim projektima tj. da 2 ili vise klasa imaju isto ime ali i zbog pomenute organizacije fajlova.

1 Like
18

Isto moze doci do konflikta custom placed __autoload() funkcije i one u composer-ovom vendor direktorijumu,
pa je bolja praksa koristiti:

spl_autoload_register(function ($class) {
    if (file_exists($file = APPPATH . 'core/' . $class . '.php')) {
        include $file;
    }
});
1 Like
19

Jep da…i zavrsio sam na tom rješenju. Osim toga, s tim je moguće napraviti poseban autoload za klase iz više različitih root foldera.

20 
spl_autoload_register (
	function($class){
		require_once 'classes/'. $class .'.php';
        }
);

require_once 'func/functions.php';