Bukankah MVC anti OOP?

Gagasan utama di balik OOP adalah untuk menyatukan data dan perilaku dalam satu entitas - objek. Dalam pemrograman prosedural terdapat data dan algoritma yang terpisah memodifikasi data.

Dalam pola Model-View-Controller data dan logika / algoritma masing-masing ditempatkan di entitas yang berbeda, model dan pengontrol. Dalam pendekatan OOP yang setara, bukankah seharusnya model dan pengontrol ditempatkan dalam entitas logis yang sama?

MVC adalah latihan dalam Separation of Concerns , arsitektur UI. Ini adalah cara untuk menyelubungi kompleksitas yang dapat terjadi pada antarmuka pengguna karena presentasi tidak dipisahkan dari konten .

Secara teori, semua objek dapat memiliki perilaku yang beroperasi pada data yang dikandungnya, dan bahwa data dan perilaku tetap dienkapsulasi . Dalam praktiknya, objek OOP yang diberikan mungkin atau mungkin tidak memiliki logika yang sesuai dengan datanya, atau mungkin tidak memiliki logika sama sekali ( Objek Transfer Data , misalnya).

Dalam MVC, logika bisnis masuk dalam model, bukan pengontrol. Kontroler benar-benar hanya perantara untuk merekatkan View dan Model. Jadi dalam model, Anda dapat memiliki data dan perilaku di tempat yang sama.

Tetapi bahkan pengaturan itu tidak menjamin penyatuan data / perilaku yang ketat. Objek yang hanya berisi data dapat dioperasikan oleh kelas lain yang hanya mengandung logika, dan ini adalah penggunaan OOP yang bisa diterima.

Saya akan memberi Anda contoh spesifik. Ini agak dibuat-buat, tetapi katakanlah Anda memiliki Currencyobjek, dan objek itu memiliki kemampuan untuk mewakili dirinya dalam mata uang apa pun yang tersedia, yang dipatok dengan dolar. Jadi Anda akan memiliki metode seperti:

public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }

... dan perilaku itu akan dienkapsulasi dengan objek Mata Uang.

Tetapi bagaimana jika saya ingin mentransfer mata uang dari satu akun ke akun lain, atau menyetor beberapa mata uang? Apakah perilaku itu juga akan dikemas dalam objek Mata Uang? Tidak, tidak akan. Uang di dompet Anda tidak dapat mentransfer sendiri dari dompet Anda ke rekening bank Anda; Anda memerlukan satu atau lebih agen (teller atau ATM) untuk membantu memasukkan uang itu ke akun Anda.

Sehingga perilaku itu akan dienkapsulasi menjadi Tellerobjek, dan itu akan menerima Currencydan Accountobjek sebagai input, tetapi tidak akan berisi data apa pun itu sendiri, kecuali mungkin sedikit keadaan lokal (atau mungkin Transactionobjek) untuk membantu memproses objek input.

MVC bekerja pada level abstraksi yang jauh lebih tinggi daripada objek tunggal, dan pada kenyataannya masing-masing dari ketiganya (model, view dan controller) biasanya akan terdiri dari banyak objek yang masing-masing memiliki data dan perilaku.

Objek-objek yang merangkum data dan perilaku adalah blok dasar yang baik untuk program-program secara umum tidak berarti itu adalah pola terbaik di semua tingkatan abstraksi dan untuk semua tujuan.

OOP tidak membatasi interaksi antara objek yang masing-masing memiliki data dan perilaku mereka sendiri.

Pikirkan analogi semut dan koloni semut: perilaku semut individu (berlarian sepanjang hari, membawa makanan) berbeda dari perilaku koloni keseluruhan (temukan tempat yang paling diinginkan, buat lebih banyak semut). Pola MVC menggambarkan struktur sosial yang diinginkan dari sebuah koloni semut, sementara OOP memandu desain masing-masing semut.

OOP juga tentang Pemisahan masalah , yaitu untuk memisahkan peran / tanggung jawab yang berbeda dalam objek yang berbeda.

MVC terpisah menjadi komponen-komponen ini:

• Model: data dan logika bisnisnya
• Lihat: representasi data
• Controller: koordinasi antara model dan tampilan.

Jadi tanggung jawab ini jelas berbeda dan memang harus dipisahkan menjadi beberapa entitas.

Dalam pola Model-View-Controller data dan logika / algoritma masing-masing ditempatkan di entitas yang berbeda, model dan pengontrol.

Model dan pengontrol adalah dua peran yang berbeda. Model memiliki status dan logika, dan pengontrol memiliki status dan logika. Fakta bahwa mereka berkomunikasi tidak memecah enkapsulasi dari salah satu - controller tidak tahu atau peduli bagaimana model menyimpan datanya, atau apa yang dilakukannya pada data ketika controller mengambil atau memperbarui beberapa bagian dari itu. Model tidak tahu atau tidak peduli apa yang pengontrol lakukan dengan data yang disediakan oleh model.

Pikirkan seperti ini: jika objek tidak dapat melewatkan data bolak-balik tanpa memecahkan enkapsulasi, Anda benar-benar hanya dapat memiliki satu objek!

Dalam pendekatan OOP yang setara, bukankah seharusnya model dan pengontrol ditempatkan dalam entitas logis yang sama?

MVC adalah pendekatan OOP - khususnya, ini adalah resep untuk memutuskan bagaimana menggunakan objek untuk mengatur program secara efektif. Dan tidak , model dan pengontrol seharusnya tidak menjadi entitas yang sama. Kontroler memungkinkan pemisahan antara model dan tampilan. Menjaga model dan tampilan independen satu sama lain membuat keduanya lebih dapat diuji dan lebih dapat digunakan kembali.

MVC adalah pola yang menggambarkan cara yang masuk akal bagi objek untuk berinteraksi; itu sendiri bukan meta-class. Pada saat itu, OO adalah tentang menggambarkan perilaku dan data entitas, dan bagaimana entitas tersebut berinteraksi. Ini bukan tentang menyatukan seluruh sistem menjadi satu objek besar.

Pengontrol tidak mewakili perilaku model. Pengendali secara keseluruhan mewakili perilaku seluruh aplikasi _ apa yang dapat dilakukan pengguna dan apa yang dapat dilihat pengguna.

Adalah salah untuk melihat pengontrol dan model sebagai satu. Mereka memiliki tujuan yang berbeda, semantik yang berbeda dan karenanya tidak boleh disatukan dalam satu objek.

Lapisan model bukan sekadar data, lebih dari lapisan pengontrol hanyalah logika.

Lapisan controller akan memiliki koleksi objek yang lengkap untuk tujuannya. Akan ada objek untuk menerima input dari tampilan, dan dari mentransformasikan input itu menjadi bentuk yang dapat diproses oleh model. Kerangka kerja Struts Java memiliki contoh yang baik dalam model Action / Form. Formulir diisi dengan input dari pengguna, dan kemudian diteruskan ke Aksi. Aksi mengambil data itu dan menggunakannya untuk memanipulasi model.

Dengan cara yang sama, lapisan Model tidak seluruhnya terdiri dari data. Ambil objek Pengguna, misalnya - Anda mungkin memerlukan kode yang mendapatkan pengguna dari database, atau kode untuk mengaitkan Pengguna dengan Pesanan, atau untuk memvalidasi bahwa alamat Pengguna berada dalam area layanan perusahaan Anda ... Anda mendapatkan gambar. Ini bukan logika pengontrol. Ini logika bisnis, dan itu menyebabkan banyak orang untuk membagi lapisan Model mereka menjadi beberapa lapisan seperti lapisan Layanan atau Manajer untuk logika bisnis, lapisan DAO (Database Access Object) untuk akses basis data, dan lainnya.

MVC bukan metode untuk mengatur operasi Model individual. Ini bekerja pada level yang lebih tinggi dari itu - ini adalah metode untuk mengatur bagaimana aplikasi diakses. View adalah untuk menyajikan data dan tindakan manusia untuk memanipulasinya, Controller adalah untuk terjemahan antara tindakan pengguna dan berbagai tampilan, dan Model adalah tempat data bisnis dan alasan bisnis untuk keberadaannya berada.

Maksud dari OOP adalah untuk mengelompokkan data dan fungsi yang dimiliki bersama . Perhitungan yang didasarkan pada sebagian data tidak selalu termasuk dalam data itu.

Dalam MVC, fungsi untuk menampilkan sepotong data (tampilan) disimpan terpisah dari data (model). Mengapa demikian? Ini khusus agar logika tampilan dapat diubah tanpa harus mengubah data yang mendasarinya. Ini membuatnya mudah untuk mengubah tampilan setiap kali Anda perlu membuat presentasi berbeda dari data yang sama: atau ketika karakteristik perangkat keras layar berubah: atau ketika Anda beralih dari Windows ke Linux; atau ketika Anda ingin dua orang memiliki dua cara berbeda dalam melihat data yang sama.

MVC tidak bertentangan dengan OOP - itu sebenarnya berasal dari aplikasi yang benar dari Object Oriented Principles.

Saya percaya Anda membingungkan data persisten yang terikat pada objek model dengan data aplikasi dari database yang berinteraksi dengan model. Model berisi logika bisnis dan aturan untuk bekerja dengan database dan melakukan transaksi. Ini mungkin mengatur dan memeriksa tanda negara internal seperti apakah ada penjualan hari ini, apakah pengguna memenuhi syarat untuk status VIP dan kemudian cabang logika sesuai ketika tiba saatnya untuk mengakses, mengatur, atau memanipulasi data atau melakukan pembelian. Ini adalah bendera yang sedang kita bicarakan ketika kita membahas objek dalam hal enkapsulasi serangkaian metode dan nilai atau data yang persisten.

Sama seperti objek model yang menyimpan data untuk menetapkan aturan bisnis apa yang sedang dimainkan, pengontrol harus, IMO, berpegang pada data keadaan aplikasi yang lebih umum yang berkaitan dengan bagaimana aplikasi harus berperilaku, seperti apakah pengguna login atau mereka memiliki kredit yang valid data kartu di tempat. Metode model akan menentukan keadaan hal-hal ini di tempat pertama tetapi masuk akal bagi pengontrol untuk mempertahankan bendera yang berkaitan dengan aliran aplikasi umum jika mereka tidak berlaku untuk bagaimana bisnis dijalankan atau transaksi data dilakukan. Setelah Anda menentukan bahwa mereka tidak masuk, jangan repot-repot model dengan pemeriksaan keadaan pengguna sampai jelas upaya login lain sedang dilakukan.

Demikian juga dengan objek tampilan yang tepat vs template HTML yang lebih khas yang Anda lihat di sebagian besar kerangka kerja sisi server. Setelah preferensi warna pengguna dimuat, itu harus menjadi pandangan yang berpegang pada data itu dan mengeksekusi di atasnya. Memuat, memvalidasi dan mengubah pengaturan adalah semua masalah model, tetapi itu hanya masalah model sampai perubahan terjadi.

IMO, tidak ada yang mengatakan pengendali tidak bisa menjadi objek komposit dengan tampilan dan model sebagai objek agregat internal. Ini sebenarnya masuk akal jika Anda menerapkan MVC pada skala yang lebih kecil seperti pabrik widget UI karena controller adalah tempat yang ideal untuk mengekspos antarmuka ke objek aplikasi tingkat yang lebih tinggi sambil mengubur data dan rincian logika tentang bagaimana interaksi Lihat dan Model. Itu tidak benar-benar masuk akal untuk objek aplikasi monolothic di mana controller benar-benar objek tingkat tertinggi.

Seperti yang saya pahami; Argumennya adalah arsitektur berbasis komponen vs OOP. Dan tanpa terlibat dalam perang agama, saya pikir mereka berdua menggambarkan hal yang sama; hanya melihatnya dari sudut yang berbeda.

Misalnya, inti OOP / OOD adalah membuat kode Anda lebih modular dan dapat digunakan kembali. Iya?

Yang persis merupakan tujuan arsitektur berbasis komponen. Jadi mereka lebih mirip daripada yang lainnya.

Saya pikir MVC hanyalah evolusi alami dari OOP dan berani saya katakan; cara yang lebih baik untuk mengatur objek Anda, pemisahan masalah dan penggunaan kembali kode.

Saya terlambat ke pesta ini, dan mempertimbangkan semua jawaban sebelum saya, saya akui saya tidak punya banyak hal baru untuk ditawarkan. Tapi menurut saya pertanyaannya bukan tentang pola itu sendiri tetapi tentang implementasinya. MVC dalam dirinya sendiri tidak cocok dengan metodologi tertentu. Bahkan, saya dapat dengan mudah membayangkan kode berorientasi prosedur dalam pola MVC (yang saya rasa Anda maksudkan).

Jadi, saya pikir pertanyaan sebenarnya adalah; apakah kita lebih rentan terhadap kode prosedural saat menggunakan pola MVC.

(dan mungkin saya hanya akan mendapatkan suara turun?)

Bukan anti, tetapi juga OOP tidak diperlukan untuk MVC.

Karena pengendali, yang biasanya diwakili oleh kelas tidak memiliki data. Untuk fungsi murni akan cukup.

Jika Anda melangkah lebih jauh dan memisahkan data dari perilaku, misalnya katakanlah model hanya bekerja pada data basis data, yang mereka ambil setiap kali fungsinya (yang bertanggung jawab atas manipulasi data) disebut (alih-alih untuk menyimpan beberapa jenis data pada instance bidang) - maka Anda dapat mengatakan hal yang sama untuk model.

Lebih jauh, jika Anda mengambil lapisan tampilan aplikasi dan membaginya dengan cara yang sama, Anda benar-benar akan berakhir dengan kesimpulan bahwa MVC tidak ada hubungannya dengan OOP, dan sangat mungkin untuk menulis implementasi MVC tanpa rasa sakit hanya menggunakan pendekatan prosedur keseluruhan. .

Dalam Opini saya OOP memiliki kelemahan karena sejak (data dan perilaku) dicetak sebagai satu entitas (Kelas) ini menunjukkan lebih banyak efek kopling daripada kohesi. Sedangkan MVC di sisi lain memiliki Model yang mengandung ... (Kacang, DAO, kelas Logika Lainnya), Pengontrol yang menentukan bagaimana kontrol harus berjalan dan Tampilan untuk menentukan bagaimana data harus ditampilkan diberikan secara terpisah. Berdasarkan hal ini, tidak masalah apakah proyek ini terlalu besar untuk dipersiapkan, dapat dengan mudah dibuat sebagai entitas terpisah selain bercampur seperti OOP. Masalahnya dipecahkan dalam pola logis seperti strategi divide n conquer dan MVC mengikuti ini paling jauh.