OOP a MVC - vidím více nevýhod než výhod

Dost se to odvíjí od složitosti projektu... Když máš pak obří projekt, tak těch "10 souborů v několika adresářích" najednou dává krásný smysl, je to logicky oddělené a když potřebuješ něco najít, víš přesně, kde to hledat. Kdybys to měl všechno v pár souborech, tak ty soubory najednou mají 1000+ řádků a hledat něco v tom, to je teprve výzva...

Další věc je, že ne vždy pracuješ na projektu sám. Často různé frameworky "vynucují" (nebo spíše doporučují) nějakou strukturu, která se ti na první pohled může zdát zbytečně složitá. Jenže pod touto strukturou pak fungují veškeré projekty, od malých po ty velké, takže když se pak někdo cizí podívá na tvůj projekt, snadněji se v něm zorientuje.

Dalším důvodem je modularita. Když máš přihlašování přes soubory s uživateli, databázi, atd., a máš to hezky a přehledně oddělené, můžeš tu samou logiku použít na vícero místech.

Všechno je to o nějaké čitelnosti kódu. A k tomu pak přispívá i to OOP. Když máš právě třeba uživatele, který má nějaké ID, username a email, tak rozhodně si můžeš z databáze vytáhnout prostě pole s jednotlivými klíči a to si všude předávat... Ale když pak půjde někdo jiný, bude chtít něco opravit a najednou tam bude prostě jen proměnná user typu array, moc mu to neřekne. Když tam bude proměnná typu User, hnedka si může tu třídu najít a vidí, co má za atributy, co může používat za funkce, atd atd... Nehledě na to, když pak potřebuješ pracovat s více uživateli najednou. Nežli mít nějaké složité 2D pole, máš prostě pole Userů a je to hnedka jednodušší a čitelnější.

TLDR: Za mě je ta největší výhoda prostě v čitelnosti. Ty věci jsou logicky a modulárně oddělené, je to jednodušší na čtení, pochopení, používání, porozumění, ačkoliv je to trochu ukecanější... :-)

unlucky:
Do čeho koukáš? Zkusil sis něco napsat třeba v Nette? Já jsem teď na jednom projektu psal formuláře, validace atd několik hodin, v Nette bych to měl za zlomek.

V čem je jinak problém?
Model = připravíš si data
View = šablona, zde to vypíšeš
Controller / Presenter = propojíš M & V (předáš data do šablony)

Nevidím v tom nic nepochopitelného.

unlucky:
Ak ťa programovanie v PHP chytí, tak sa časom k OOP, resp. MVC nevyhnutne dostaneš, už len z praktických dôvodov, ako píše Kcko.

RastyAmateur:
„Ale když pak půjde někdo jiný, bude chtít něco opravit a najednou tam bude prostě jen proměnná user typu array, moc mu to neřekne. Když tam bude proměnná typu User, hnedka si může tu třídu najít a vidí, co má za atributy, co může používat za funkce, atd atd... Nehledě na to, když pak potřebuješ pracovat s více uživateli najednou. Nežli mít nějaké složité 2D pole, máš prostě pole Userů a je to hnedka jednodušší a čitelnější.“

S týmto celkom nesúhlasím, aj procedurálny, aj objektový kód sa dá napísať aj čitateľne, aj nečitateľne.

Stroganov:
To já ovšem netvrdím. Já tvrdím, že pokud někde reprezentuješ nějaký objekt jakožto dictionary (případně v PHP jako pole se string klíči), je tento kód nepochybně mnohem těžší na čtení i udržitelnost. Protože prostě klíče to může obsahovat už z principu jakékoliv. Takže pokud chceš pro čitelnost někde mít výčet použitých klíčů, popř. i datové typy hodnot, musíš to psát někam do komentáře, dokumentace. Tuhle dokumentaci už ti ale pak nikdo (např. IDE) nekontroluje, takže jakmile to někde změníš a zapomeneš upravit dokumentaci, jsi v háji.

Rozhodně mi přijde přehlednější dát někam typ "User" a pak si jen najít deklaraci této třídy, než viděl typ "array" a hledat všechna použití napříč kódem a řešit, co za pole se tam vlastně strká.

Abych doplnil Rastyho, tak pokud používáš objekty, klidně jen jako tupé přepravky dat a dopíšeš si / vygeneruješ gettery / settery tak To potom IDE napovídá.
Což v případě jednodušších struktur (pole dat) NE (nemá to co napovídat).

Navíc časem se rozhodneš ty data zvalidovat, tak jednodušše upravíš konkrétní getter.

Reakce na unluckyho:
„V případě velkého webu je celkem těžké se v tom vyznat. […] V tom vidím zmatek.“
To je asi individuální. Já osobně raději najdu jeden z tisíce souborů, který je krátký (dejme tomu maximálně 2 obrazovky), než jeden z desítky, ale s tisícem řádek. Přece jenom delší čas strávím jeho editací než hledáním, a pak ocením, že se nemusím zabývat kódem, který se aktuálního úkolu netýká. Příklad: Chci změnit HTML šablonu článku. Proč bych měl v tu chvíli vidět kód, který se stará o načtení článku z databáze?

„Ale proč to nezpracovat přímo v M?“
Co bych ale považoval za objektivní výhodu MVC vs. mít všechno pohromadě, je podpora principů separation of concerns a DRY. Odvoláváš se na to, že programuješ rozsáhlejší aplikaci. Ta může mít webové rozhraní, RSS kanál na čtení novinek a REST API. Dejme tomu, že nejprve programuješ webové rozhraní a rozhodneš se data na míru pro něj zpracovat už v modelu. A co až budeš potřebovat data v trochu jiném tvaru pro RSS nebo REST API? Dvakrát celý model (připomínám, že sem patří i business logika aplikace) zkopíruješ a upravíš ho pro potřeby RSS, resp. API? Nedává větší smysl mít model nezávislý na tom, v jakém tvaru data zobrazím klientovi? Mít stejný model pro web, RSS i API? A pak data přeformátovat v controlleru, který je specifický pro danou reprezentaci?

„OOP jako balíček s funkcema“
Balíčky funkcí jsou jen jedna část. Možná bych i řekl jen část části. Je to část prvního OOP pilíře, tzv. zapouzdření. Nesmí se ale zapomenout na abstrakci, dědičnost a polymorfismus. Bez nich by to nebylo skutečné OOP, ale jenom balíčky funkcí.

unlucky:
> Je toto MVC:
>
> root - article.php
> function - article_funkce.php
> template - article.tpl
Prosímtě, neplácej si něco svého. Bude to beztak shit ... Vyzkoušej si tohle doc.nette.org/cs/10-reasons-why-nette a za nějakou dobu se tomuhle topicu zasměješ.

unlucky:
V tom případě to piš po svém a good luck.

unlucky:
Nepochopil jsem smysl téhle debaty. Buď chceš vytvářet konkurenceschopný software a pak návrhové vzory včetně OOP používat prostě musíš, tady není co řešit. A i použití nějakého rozšířeného frameworku je taky nutnost. Nikdo nebude zvědavý na tvé řešení základních algoritmů a už vůbec nebude ochoten za ně platit a spoléhat na jejich kvalitu, aktuálnost a bezpečnost.

No a nebo něco plácáš sám pro sebe a pak je to jedno, můžeš to bastlit jak chceš.

Unlucky
Mvc = model, view, controller. Jedna se o tri samostatne vrsty, pricemz kazda zastava svoji samostatnou funkci. Je to pak lepsi z pohledu udrzitelnosti a dalsiho rozsireni.samozrejme je nutne mit nejake zaklady OOP. Kazdy nejak zacinal, proto bych doporucil postup typu:
1) naucit se zaklady OOP
2) naucit se pracovat s frameworkem a pochopit jeho strukturu
3) az teprve pak muzes zkusit si navrhnout nejake sve reseni.

unlucky:
"Programuji dlouho" a "ne OOP" je oxymoron.
Každý kdo OPRAVDU programuje dlouho musí OOP znát (já se teď nebavim o PHP, nikdy jsem v něm nic nedelal mimo semaforu na střední). OOP mozna nemám příliš v lásce, ale nemít ho v lásce a neumět ho jsou dvě různé věci.
Už jenom to "rozdělování do souborů" naznačuje že to s tím programovanim nebude tak horký - v OOP nejde o soubory, možná v PHP, nevím. Jde o třídy a možná o moduly/package  v kolika souborech je to fyzicky zapsaný je vedlejší a je to spíš o logické organizaci.