Az MVC az OOP-vel hogy jön össze?

Egyik sem zarja ki a masikat.

Amit te csinaltal 1 db osztaly tul "nagy", szet kellett volna valasztani.

Az nem OOP, hogy mindent egybe bepakolok.

Nalad a liras alapjan azt, hogy HTML levelet kuld valami ki lehet szedni ugy, hogy kap egy templatet, meg parametereket es cimzett(ek)et, majd ebbol keszit egy levelet es kuldi.

Az urlapot megintcsak kulon osztaly tudja kezelni megfelelo parameterezessel.

MVC-ben is vannak neked kulon kontrollerek (amik szinten osztalyok), amik kulon-kulon feladatert felelos osztalyokat fognak ossze, vannak templatek es template kezelo osztaly.

Egy irdatlan primitiv pelda/"MVC framework"-re pl:

[link]

A Controller mappaban ott egy Base controller, amibol szarmaztathatoak a sajatok ez csak ad par helpert es alap parametereket.

Az src-be lehet pakolaszni a mukodeshez osztalyokat, a controllerek csak parametereket szurnek, csinalnak par ellenorzest, majd peldanyositjak es hivjak a megfelelo osztalyokat.

(Itt jelenleg csak 1 wrapper van az altorouterhez, amit a keresek feldolgozasaert es routeolasaert felel.)

A "belepesi pont" itt a public mappaban az index.php az peldanyosit egy routert (ez most a Router.php amiben az utvonalak vannak jelenleg), csinalja meg a matchelest es a megfelelo controllerek peldanyositasat es meghivasat.

A sajat kulon logika szinten mehet az src-be, kulon osztalyokba szepen, mert igy egyreszt sokkal atlathatobb, hogy mindennek megvan a helye, masreszt (ami fontosabb) tesztekkel jol lefedheto.

Mondjuk mert ugy tesztelhetoek a reszek fuggetlenul es jobban elkulonulnek a szerepkorok, valamint sokkal jobban bovitheto a dolog.

Kod ujrafelhasznalas?

Ennyi erovel minek egyaltalan OOP meg MVC?

Siman ossze lehet tolni mindent 1-2 fileba, max par fuggvennyel es kesz.

Pillanatok alatt megvan, csak utana soha az eletbe ne akarja hozzanyulni.

Nem olvastam el az eddigi válaszokat és magyarázatokat, így előfordulhat, hogy 2x mondom el ugyanazt.

OOP: [link]

MVC: [link]

Úgy képzeld el mint egy gyárat. Vannak összeszerelő üzemek, alkatrész gyártók és a többi...

Ugye egy alkatrész gyártáshoz, más tudás, más eszköz kell. Így azt ott csinálják. Meg van az alkatrész, akkor azt lehet továbbítani, kiadni.

Hogy az alkatrész hova kerüljön (pl. egy csavar) azt egy külön szerv dönti el, hol van rá szükség. [Controller példának kedvéért]

Majd az adott alkatrész (csavart) felhasználják az összeszerelőben.

Létrejött egy termék.

Hasonló módon pepitában a MVC is.

- Controller egy olyan objektumok halmaza, ami vezérli az egész rendszert. Azt, hogy az szoftveres ülteti logikát hova építed, az már más kérdés.

- Model nem más mint az adatbázis adatainak képe. Azaz itt tárolják, amit adatbázisból kiolvastak ill. írni akarnak.

- View nem más mint a megjelenítés.

Pl.: Webfejlesztésben

http kérés jön valamilyen paraméterekkel. Ezt a Controller feldolgozza, majd a megfelelő üzleti logika függvényeit hívja. Ha kell az adatbázist írni/olvasni, akkor a Model-hez fordul segítségért.

Ha már minden output előállt, akkor az átadja a View-nak, hogy generáljon belőle HTML kimenetet.

És ez az amit látsz.

De C++/Java/stb nyelveknél nem úgy működik, hogy elejétől a végéig lefut a kód, és utána látod, mint PHP esetén, hanem M, V és C relatív párhuzamosan fut, attól függően, hova nyúlkálsz.

Következő classokat csinálnék:

a) Levél küldéssel foglalkozik (üzleti logika)

b) Űrlap adatot dolgoz fel ír/olvas, megjelenítésre meg odaadja a View-nak amiket kell (Üzleti logika)

c) Űrlapot jelenít meg (View eleme)

d) Adatot tárol (Model elem)

Itt az adatok nem sérülnek, mert az attribútumok PRIVATE-ak. Más szóval, kívülről nem férhetők hozzá, csak az adott osztály képes. Getter/setter meg ép arra jó, hogy ha írni akarnád, akkor letudod ellenőrizni, hogy tényleg valid (helyes) azaz input, amivel felül akarod írni az attribútumot.

Teszem azt, egy attr. csak páros számot tárol, setter meg kap egy páratlant. Akkor a setter metódusban leellenőrzöd, hogy tényleg páros-e, ha nem akkor vagy nem írja felül, vagy teszem azt: egy visszatérési értéket generálsz, hogy false ha nem írta felül, és true ha igen.

Itt adatok nem sérülnek, és azaz sincs semmi baj, ha adatot adogatsz egyik helyről a másikra. Meg egyébként is: API-k erről szólnak.

Adsz valami inputot, csinál valamit, és vissza ad valamit amivel te bajlódsz tovább.

[link]

Ezt olvasd el. A "A COM+" és a ".NET" témák már nem kellenek.

"gyengíti azt az OOP-s alapelvet, hogy minden feladatot abban az osztályban kell megoldani, ahol az adatok rendelkezésre állnak"

De ez nem igy van, ilyen esetben 1 db osztaly eleg lenne mindenre, mert abban ugyebar minden adat ott van.

Az, hogy kivulrol nem piszkalod az osztaly belso allapotat, az tiszta sor, a masik valaszolo megadta a kulcsot hozza, az adattatgok private-ra vannak rakva es csak gettereken/settereken keresztul fersz hozzarjuk (vagy ugy sem).

Igy maris minden osztaly, magaban foglalja majd az o reszfeladatahoz szukseges dolgokat, ugyanakkor minden osztaly csak 1-1 kisebb, specifikus feladatert fog felelni.