Jedna klasa za korisnika ili zasebne za username, email, itd.?

Pozdrav!

Kad pravim klasu za korisnike dali je bolje napraviti posebne klase za username, email itd.

ili je ovo bolje staviti sve u jednu klasu User.[indent]_________________
[color=green][size=4]Naslov “Pitanje u vezi klase” promijenjen u naziv koji odgovara predmetu teme. Neka posluži autoru kao smjernica za buduće imenovanje tema.

  • tsereg[/size][/color][/indent]

Jel’ tako da ti uopće nisi skužio Object Oriented Programming paradigmu?

Naime da jesi ovakova pitanja uopće nebi postavljao. Iz tog razloga ti predlažem da najprije pročitaš 2-3 knjige čistog teoretskog teksta vezanog uz programiranje i objektno orijentirano programiranje.

Inače odgovor na tvoje pitanje je staviti sve u klasu User jer su to sve atributi Korisnika. Najlakše si to možeš možda dočarati kroz tablicu u bazi podataka.

Nema točnog odgovora na to pitanje, sve ovisi gdje i kako će se koristiti te funkcije. Ako će se stvarno koristiti ako kod dodavanja / ažuriranja korisničkig podataka onda sve stavi u jednu klasu.

Dvije opaske:

  1. Nije potrebno pisati

Isto dobiješ i sa

  1. funkcija UserName::valid() je skroz naopaka. Prvo je pogrešna i vratiti će false za dobro ime. Drugo, puno je pametnije definirati koji znakovi su dozvoljeni nego koji nisu.

ne mogu definirati znakove koji su dozvoljeni! Pošto u mene na korisničkom imenu su svi dozvoljeni znakovi osim

-=+*%#\[\]& \/"\';:.,<>()|{}~

jer kad bi definirao znakove koji su dozvoljeni morao bih pisati i koneska i arapska i čirilicu i sva slova.

a ova klasa mi za email ne koristi se samoza korisnicki email već za sve email adrese u aplikaciji

Pa kako su atributi korisnika ova klasa UserName ona je zasebna klasa i nemora se koristiti samo za korisnike, kao i klasa eMail

i preradio sam klasu vako mislim da je bolje

Tvoj razred UserName bi se zapravo trebao zvati UserNameInputValidator. Slično i drugi razredi. Oni (ili nešto ne baš takvo, ali načelno slično njima) bi imali smisla u nekom prilično kompleksnom sustavu gdje bi oblici pojedinih podataka bili konfigurabilni, odn. programski proširivi od strane implementatora sustava. Za tvoje potrebe možda malo preambiciozno u smislu da ti razredi nikada neće biti stvarno iskorišteni u kakvom polimorfnom skupu sebi sličnih. Drugim riječima, da budem prost, samo malo “natežeš kožicu”. Objektno-orjentirani dizajn nastaje zapravo opažanjem, uočavanjem stvarnih sličnosti u stvarnim “modulima koda” (“Vidi! Ovaj komad koda i podaci i ovaj komad koda i podaci su dosta slični po nekom svom ponašanju ili podacima.”), te izdvajanjem tih sličnosti i njihovim bilježenjem kao “baznih” značajki više različitih modula – tada u igru tek ulazi OO-sintaksa koja omogućuje da tu relaciju “baznog” (zajedničkog) i onog “deriviranog” (vrlo sličnog, ali ne baš posve istog) izraziš i nekom zgodnom formalnom notacijom zamišljenom za tu svrhu. Ali, OO-programski jezik uopće nije potreban da bi se programiralo u OO paradigmi. Vrati se na pred-OO-vski PHP i izrazi istu ovu misao koju si izrazio s tim svojim razredima tamo. Ako ti se tada pričini da ona nema smisla, onda jednako nema smisla i ako je umotaš u “celofan” u obliku nekih ključnih riječi poput “class” i sličnih.

A šta mislite dali je vako bolje da sve stvari koje treba provjeravati stavim u klasu validation

i sad pozivam klasu vako

Ako tebi tako odgovara samo naprijed.

Možda umjesto onih dugačkih switch/case možeš iskoristiti array:

Obolio si od opasne bolesti instant OOP. Uspori malo. Prouči koji library.
Mislim da je tome kriva i malo današnja scena koja traži puno OOP a na kraju od samog developera se i ne traži previše.
Sumnjam da bilo koji developer u nekim enterpreis orijentiranim firmama mora razmišljati o desing patternima i OOP principima.
A i praksa će ti pokazati da se ipak traži efiktivno završavanje nečeg a ne kvaliteta.
No ako cijelo vrijeme imaš na umu kvalitetu doći će ti s vremenom.
Za sada bi ti cilj trebao biti da znaš manje više sve termine u OOP, a pusti se ovih pitanja za sada jer puno koda ćeš morati prožvakati da bi našao odgovor na njih.

Ako uzmeš svoju klasu validation user name i pročitaš što ti je tsreg napisao onda bi primjetio da stvar nevalja. Na veličinu username bi mogao validiratiti veličinu bilo kojeg stringa (recimo i password). Ti si to hardkodirao provjeru na veličinu i još ktome provjeru je validan username.
I sutra ćeš to isto raditi za password.
Pa onda za mail, etc…

Znam da sam previše dosadan ali bih vas molio da mi kažete svoje mišljenje i o ovoj klasi dali valja vako

Hvala!

Kratko i jasno, ne valja. Nemam sad vremena detaljnije objašnjavati, ako uhvatim vremena objasnim kasnije, ali ne, ne valja.

Što ne valja?

Dati ću ti primjer koda iz vlastitog frameworka, te kratke smjernice što i kako…

Kako bi pojednostavnili problem, i rješenje - ono što napišem ima ulogu samo da ti principijelno demonstrira kako bi najbolje izgledalo ovo što te zanima, dalje je na tebi da to razradiš.

Ima se file index.php iz kojeg se poziva centralna klasa aplikacije (AppCore):

Sada bi unutar aplikacije slao upit na sljedeći način:

Prilikom učitavanja aplikacije klasa AppCore prikupi sve relevantne podatke, koji se mogu koristiti bilo gdje unutar aplikacije. Ovakvim pristupom eliminira se razmišljanje oko inicijalizacije pojedine klase, sve potrebno za ispravan rad aplikacije je učitano unutar statičkih varijabli (obrati pažnju na prethodni primjer).

Još par sitnica… Klasa “User” treba sadržavati svojstva vezana za korisnika, dakle ne bi trebala sadržavati provjere ispravnosti imena i slično. Za to bi bilo praktično napraviti jednu klasu npr. “UserUtil”, koja bi sadržavala sve provjere vezane za korisnika (ime, lozinka, email,…). Zatim sve “Util” klase koje napraviš učitaš jednostavno pomoću funkcije “__autoload()”.

Sada si dobio da unutar klase npr. “UserRegister” možeš napraviti sljedeće:

Puno se toga može napisati na ovu temu, zato bilo najbolje da ideš korak po korak: napraviš dvije datoteke i u njima radiš kombinacije sa OOP, te vježbaš primjere koji su dostupni na php.net

Trebao bi imati abstraktnu klasu validator u kojoj bi definirao zajedično svim validatorima, a i koje metode mora implementirati svaka konkretna klasa validacije.
A to je u tvoj slučaju metoda validate();
I u tu metodu validate pozivaš privatne metode konkretne klase. I imaš jedan parametar $stopValidationOnError, koji nakon prvog errora vraća grešku ako je true (neka bude default), ili ako je false vraća sve errore.
Metode za manipulacijom errora držiš u abstraktnoj klasi.

To što sam ti napisao nije ispravno, nije pravilno, to je samo jedan način izrade, način koji se drži više principa nego tvoj pristup.

Probaj to gore izraditi, potrudi se:)

Ja mislim da je najbolje da radim kako je meni najlakše i kako mi odgovara.

Pošto vidim da niko ne programira isto 100 ljudi i nijedan ne misli isto.

Tako je i najbolje onda da ne postavljaš pitanje o našim mišljenjim jer ćeš ionako raditi kako ti hoćeš.

[quote=“susok”]Ja mislim da je najbolje da radim kako je meni najlakše i kako mi odgovara.
[/quote]
Baš zato je dobar OOP, da zaobiđe samovolju i uredi stvari.
Evo kako bi ja to napravio. Napisati ću samo metode i klase, ti obavi onaj teži dio:)

Vidiš da je svaka klasa puno jednostavnija treće klase ne moraju znati s kojim validator rade, samo očekuju interface.
I to je to.

Ukoliko si napravio ovo gore što sam ti naveo, a pretpostavljan da nisi:)

Ta sitnica koju sam ti napisao ide u skladu sa osnovnim OOP načelima.
Tu je Encapsulacija. Tu ti je mogučnost polimofizma, i tu ti je nasljeđivanje.
I tu ti je još jedna sitnica “program to interface not implementation” što ti ne radiš.

I evo ti jedan library u PHP koji je pokušao biti čim više OOP:

http://code.google.com/p/php-socket-game-server/

I ne treba da shvatiš što se događa, ne treba da razumiješ kod, već samo da možeš objasniti tok aplikacije. E onda si tek spreman da razmišljaš što i kako u OOP.
U proceduralnom programiranju sve je jasno no u OOP se lagano izgubiti, pa zašto za početak ne “dotjerati” sebe do te razine da se ne “izgubiš” u kodu.

Ufff slažem se sa mišljenjem, prvo malo pročitati o teoriji OOP-a neke knjige i nešto naučiti s razumjevanjem prije nego što se krene bubati kod jer je netko ili neki tutorial tako rekao a bez da ga se razumije zašto je to baš tako napravljeno.

Na žalost danas je lako nazivati se programerom a puno ljudi neke stvari uopće ne razumije ni nakon puno godina rada, vidim to u firmi kod nekih ljudi svaki dan i takvi najveće pizdarije naprave i naviše posla iza njih imaš.


Copyright © 2020 WM Forum - AboutContact - Sponsored by: Mydataknox & Webmaster.Ninja