|
Ono što je najbitnije jeste ono što i sam već shvataš.
Ukoliko ti neki pristup arhitekturi koda ne odgovara jer predstavlja suvišnu komplikaciju bez benefita, onda to itekako treba zaobići. Za validaciju jedne forme ti sigurno nije neophodan objektno orijentisani pristup jer tu validaciju forme nećeš nadograđivati. Forma takođe neće biti korišćena od strane 50+ komponenti neke veće frontend aplikacije i neće biti deo tima od 50+ programera.
I to ne važi samo za validaciju forme, jer je očigledno jednostavna komponenta u pitanju, nego je to pravilo i za spomenute slučajeve od 50+ komponenti (objekata i modula) koje čine jedan sistem. Ne samo da nije neophodno sve organizovati po prinipu "sve treba biti enkapsulirano" već je to i problem - softver jednostavno postaje bespotrebno komplikovan i samim tim je teži za održavanje. Po sličnom principu kao kada znaš da se neka vrednost neće menjati, pa je jednostavno logičnije upisati tu vrednost direktno kao String ili Int parametar nekog bloka ili funkcije, umesto toga što bi je na početku koda definisao kao promenljivu i bespotrebno gomilao namespace, isto tako postoje šanse da se neka komponenta neće nagorađivati ili da njeno postojanje neće znatno uticati na skalabilnost arhitekture, pa je tako i nije neophodno odvajati i zasebno pakovati.
Dakle, glavna ideja ili princip objektno orijentisanog programiranja jeste organizacija komponenti tako da one međusobno znaju što manje jedna o drugoj. Taj princip, možeš u skoro svakom programskom jeziku da implementiraš na više različitih načina, a jedan od njih svakako jeste i funkcionalan pristup koji si spomenuo.
U Javascriptu nije ništa manje bitno pristupiti objektno orijentisanim principom nego što je to u nekom drugom jeziku. Javascript, iako važi za neskalabilan jezik sa premalo sintakse i bez ozbiljnog type sistema, nudi mnogo više mogućnosti za primenu različitih paterni organizacije koda ili stilova programiranja, jer je u osnovi kreiran tako da se nedostaci lako mogu popuniti.
Ukoliko bih krenuo da ti pišem o tome kako je iz Prototipnog nasleđivanja u Javascriptu kreirano Klasično nasleđivanje objekata (i kako je to sakriveno iza class i new sintakse u ES6) i zašto je to mnogo bitno znati ali i zašto to nećeš toliko primenjivati zarad enkapsulacije, već ćeš tvoj kod organizovati na funkcije i module (module pattern) i koristiti npr. Typescript, ovaj post bi bio 10 puta duži 😃
Angular je OK framework za veće frontend aplikacije i iz njega možeš da naučiš kako treba da izgleda organizacija koda uz MVC ili MVVM paterne koje su nezaobilazne za skoro sve što se može nazvati aplikacijom. Ukoliko ipak ne znaš kako bi to implementirao u osnovi bez framework-a, mislim da će ti JS TodoMVC primer pomoći da bar kreneš u tom smeru.
Tu nemaš primer kako da implementiraš abstrakciju nad two-way data-binding-om (ili three-way) ili šta god što poseduje jedan malo veći frontend framework kao što je Angular, ali će ti svakako biti dovoljno za početak. Najbolje bi bilo da paralelno uz razvoj neke aplikacije nad nekim framework-om pokušaš i da sam sve implementiraš nad nekim svojim test projektom jer ćeš tako najbolje naučiti sve što je bitno.
Javascript, kao razvojna platforma je preterano brzo porastao za poslednjih par godina (How it feels to learn javascript in 2016). Postoji nenormalno mnogo alata, kompleksan toolchain i mnogo frejmvorka i praktično ne postoji "najbolji način". Dokle god ti sam znaš šta je najbolje za tvoj tip projekta, to je najbitnije.
p.s. članak koji si linkovao je iz 2009. - već u prvom komentaru možeš i da vidiš da je neko skrenuo pažnju na to da nisu navedene sve varijante kreiranja objekata u Javascriptu. Osim toga imaj u vidu da je u Javascriptu sve objekat se sve ponaša kao objekat, pa čak i String - "default@mycity.rs".split("@")[1]; // => mycity.rs
|
