Pertanyaan Bermain! kerangka kerja menggunakan statika


Waaah, Mainkan! Kerangka memiliki begitu banyak metode statis. Di mana saya pergi ke sekolah, kami diberitahu tidak akan pernah untuk menggunakan statika apa pun, namun Mainkan! menggunakannya seperti tidak ada hari esok. Apakah itu baik-baik saja? Jika ya, mengapa?

Kami (7 orang dan saya) berencana untuk menggunakan Play! kerangka kerja untuk proyek yang melibatkan aplikasi web. Kami memutuskan untuk melakukannya dengan Play! karena terlihat cukup menyenangkan untuk dilakukan, kita semua sudah tahu Java dan tugasnya cukup sulit sehingga kami ingin fokus pada tugas yang sebenarnya daripada belajar cara memprogram dalam bahasa yang berbeda.

Kami selalu diberitahu, bagaimanapun, TIDAK AKAN PERNAH untuk menggunakan 'statis' dalam program Java apa pun yang kami kembangkan, tetapi ketika saya melihat Play! ... Yah ... sekitar separuh metodenya statis. </ melebih-lebihkan>

Saya kira, paling tidak, kita bisa menggunakan objek tunggal (dengan menggunakan Scala, misalnya ^^) untuk memprogram proyek kami, tapi saya cukup peduli pada berapa banyak statika sebenarnya ada dalam kerangka itu sendiri.

Jadi, haruskah saya khawatir tentang ini? Apakah cara bermainnya! pengembang diprogram membuatnya sehingga semua statika ini tidak menimbulkan masalah?

(Sebagai contoh, utas ini memiliki kata-kata kasar tentang mengapa anggota statis harus dihindari di semua biaya.)


76
2018-03-04 11:06


asal


Jawaban:


Mainkan hanya menggunakan metode statis ketika itu masuk akal:

  • di lapisan pengontrol, karena pengontrol tidak berorientasi objek. Pengendali bertindak sebagai mapper antara dunia HTTP (yang tanpa negara, dan berdasarkan permintaan / respons) dan lapisan Model yang sepenuhnya berorientasi objek.
  • di lapisan model untuk metode pabrik, seperti findAll (), count (), create () yang tentu saja tidak bergantung pada instance tertentu
  • di beberapa kelas play.libs. * yang menyediakan fungsi utilitas murni

95
2018-03-04 12:31



Kerangka kerja bermain bukanlah demonstrasi yang baik ketika menggunakan statika yang tepat, juga tidak membuktikan bahwa guru Anda salah. Bermain adalah semacam kecurangan, memecahkan masalah statika di luar bahasa Jawa.

Masalah utamanya adalah bahwa Anda harus memproses beberapa permintaan HTTP secara paralel, dan bidang statis adalah "global". Jadi Anda akan membutuhkan satu contoh per utas (atau bahkan lebih baik, satu contoh per permintaan HTTP) untuk hal-hal tertentu, namun beberapa dari hal-hal tersebut dikembalikan oleh metode statis di Play. Itu berhasil karena Mainkan! menggunakan ThreadLocal-sangat berat, dan itu memecahkan masalah statika di luar bahasa Jawa. Tapi itu bukan segalanya. Beberapa orang mengatakan bahwa metode pengendali benar-benar statis. Tentu, tetapi di Jawa biasa akan merepotkan, karena Anda tidak dapat mengakses data spesifik permintaan tanpa semacam awalan, seperti req. di req.session, dan kemudian Anda masih harus mendapatkannya req dari suatu tempat, seperti sebagai parameter metode pengendali statis, yang bahkan lebih merepotkan. Namun di Play Anda bisa langsung menulis session dan seperti, mereka hanya bidang statis. Itu karena Play menggunakan instrumentasi bytecode untuk mengubah semua referensi medan statis menjadi sesuatu yang lebih pintar. Sekali lagi, solusi di luar bahasa Jawa. Itu bukan bidang statis di bagian akhir.

Jadi, secara umum, hindari statika non-final. Bermainlah melakukan sihir untuk Anda, jadi jangan takut pada mereka dalam hal ini.


34
2017-08-04 19:15



Dari pandangan yang sangat singkat, saya akan mengatakan itu masuk akal: permintaan web tidak bernegara, jadi di sana aku s tidak ada objek untuk menerima permintaan (= metode). Jadi, memetakan URI seperti "/ artikel / arsip? Tanggal = 08/01/08 & halaman = 2" ke metode statis yang disebut archive() pada, saya kira, kelas aplikasi Anda masuk akal.


15
2018-03-04 11:12



EDIT Sekarang di Play 2.4, suntikan dilakukan secara otomatis. Jadi, tambahkan saja @ di awal jalur pengontrol dalam file routes akan membuat trik:

GET     /                  @controllers.Application.index()

Untuk versi lama (2.1 hingga 2.3) Anda harus mengganti getControllerInstance di kelas Global, seperti dijelaskan di Documentantion.


8
2017-12-14 01:59



Seperti halnya dalam pemrograman, tidak akan pernah tidak pernah jawaban yang benar. Seperti selalu. Selalu ada pengecualian dan jawaban yang benar selalu 'tergantung'.

Memang benar bahwa dalam OO murni (yang saya semua lakukan) hanya ada sedikit ruang untuk statika. Tetapi juga benar bahwa kadang-kadang mereka masuk akal.

Contoh klasik adalah metode utilitas. Tentu, akan lebih baik jika kita bisa menambahkannya abs() metode untuk Integer. Tetapi kita tidak bisa; jadi kami terjebak dengan Math.abs(int i).

Saya cenderung berpikir itu hanya benar untuk membuat metode statis ketika tidak ada hubungannya dengan contoh itu sendiri. Misalnya, di kelas Person, Anda bisa memiliki metode yang mengambil daftar orang, dan mengembalikan jumlah orang yang berulang tahun hari ini. Mungkin Anda hanya dapat melakukan ini di kelas itu sendiri jika data yang diperlukan untuk melakukan perhitungan bersifat pribadi (sesuatu yang seorang OO puristik akan mengerti;)) tetapi tetap saja metode tersebut jelas tidak ada hubungannya dengan satu Person tunggal.

Hal lain adalah kelas internal. Anda sering ingin membuatnya statis jika Anda tidak membutuhkan hubungan dengan jenis yang mengandung.

saya tidak pernah lihat Bermain! tetapi jika Anda mengatakan bahwa lebih dari 50% itu statis, maka saya kira itu mungkin dirancang dengan buruk. Itu tidak terkecuali; banyak kerangka kerja. Jangan biarkan itu mengecewakanmu. Pasti tidak belajar darinya!
Tetapi jika berhasil, Anda masih bisa menggunakannya.


5
2018-03-04 12:11



Masalah utamanya adalah bahwa metode statis hanya memiliki akses ke metode dan bidang statis lainnya, yang menghasilkan 'static cling' di mana metode statis harus bertemu dengan sisa aplikasi (yang berisi kolaboratornya) melalui bidang statis umum (s) , yang mengarah ke ketidakfleksibelan.

Disclaimer: Saya tidak tahu banyak tentang 'bermain!'


4
2018-03-04 11:41



Metode pengontrol statis tentu saja menjadi perhatian utama dalam Play! kerangka kerja, dan setelah melakukan beberapa pengujian, itu adalah alasan utama saya tidak melakukan Play! dalam proyek. Anda benar-benar dapat melihat ini di mana di proyek FOSS di mana Mainkan! digunakan. Ada sedikit atau tidak ada pengujian Pengendali. Alasannya, dengan metode statis, DI menjadi sulit. Di sinilah mereka harus menghabiskan lebih banyak waktu dengan ASP.NET MVC, dari mana Play! sudah mengambil sedikit inspirasi.

Biasanya Anda memiliki konstruktor seperti ini:

public HomeController( IService service ) {
   _service = service;
}
public Index() {
   var data = _service.getData();
   return View( data );
}

Kemudian Anda menggunakan DI untuk menyuntikkan implementasi IService ke Controller. Intinya adalah bahwa dalam pengujian Anda, Anda dapat memberi tahu IService sesaat sebelum menjalankan Controller, dan kemudian menguji hasilnya berdasarkan IService yang baru saja Anda hasilkan.

Di Play ini menjadi sangat sulit. Dengan demikian pengujian unit pengontrol menjadi sulit. Artinya, bagi saya, masalah yang signifikan. Karena itu saya akan cenderung mencari kerangka kerja selain Play! di dunia Jawa. Heck, mengapa tidak pergi dengan yang asli dan hanya menggunakan JRuby?


4
2017-10-29 12:36