Strategi apa yang Anda gunakan untuk penamaan paket di proyek Java dan mengapa? [Tutup]

Saya memikirkan hal ini beberapa waktu yang lalu dan baru-baru ini muncul kembali karena toko saya sedang melakukan aplikasi web Java pertama yang sebenarnya.

Sebagai intro, saya melihat dua strategi penamaan paket utama. (Untuk lebih jelasnya, saya tidak mengacu pada keseluruhan bagian 'domain.company.project' ini, saya berbicara tentang konvensi paket di bawahnya.) Bagaimanapun, konvensi penamaan paket yang saya lihat adalah sebagai berikut:

1. Fungsional: Memberi nama paket Anda menurut fungsinya secara arsitektural daripada identitasnya menurut domain bisnis. Istilah lain untuk ini mungkin penamaan menurut 'lapisan'. Jadi, Anda akan memiliki paket * .ui dan paket * .domain dan paket * .orm. Paket Anda adalah potongan horizontal, bukan vertikal.

   Ini jauh lebih umum daripada penamaan logis. Sebenarnya, saya tidak percaya saya pernah melihat atau mendengar proyek yang melakukan ini. Ini tentu saja membuat saya curiga (seperti berpikir bahwa Anda telah menemukan solusi untuk masalah NP) karena saya tidak terlalu pintar dan saya berasumsi bahwa setiap orang pasti memiliki alasan yang bagus untuk melakukannya dengan cara yang mereka lakukan. Di sisi lain, saya tidak menentang orang yang hanya merindukan gajah di kamar dan saya tidak pernah mendengar argumen sebenarnya untuk melakukan penamaan paket dengan cara ini. Ini sepertinya menjadi standar de facto.

2. Logis: Memberi nama paket Anda sesuai dengan identitas domain bisnis mereka dan memasukkan setiap kelas yang berkaitan dengan fungsionalitas vertikal ke dalam paket itu.

   Saya belum pernah melihat atau mendengar ini, seperti yang saya sebutkan sebelumnya, tetapi itu sangat masuk akal bagi saya.

   1. Saya cenderung mendekati sistem secara vertikal daripada horizontal. Saya ingin masuk dan mengembangkan sistem Pemrosesan Pesanan, bukan lapisan akses data. Jelas, ada kemungkinan besar saya akan menyentuh lapisan akses data dalam pengembangan sistem itu, tetapi intinya adalah saya tidak menganggapnya seperti itu. Artinya, tentu saja, adalah ketika saya menerima perintah perubahan atau ingin menerapkan beberapa fitur baru, alangkah baiknya jika tidak perlu mencari-cari di sekumpulan paket untuk menemukan semua kelas terkait. Sebaliknya, saya hanya melihat paket X karena apa yang saya lakukan berkaitan dengan X.

   2. Dari sudut pandang pengembangan, saya melihatnya sebagai kemenangan besar memiliki paket Anda mendokumentasikan domain bisnis Anda daripada arsitektur Anda. Saya merasa domain hampir selalu menjadi bagian dari sistem yang lebih sulit untuk dikuasai dimana arsitektur sistem, terutama pada titik ini, hampir menjadi biasa dalam implementasinya. Fakta bahwa saya bisa datang ke sistem dengan jenis konvensi penamaan ini dan langsung dari penamaan paket tahu bahwa itu berkaitan dengan pesanan, pelanggan, perusahaan, produk, dll tampaknya sangat berguna.

   3. Sepertinya ini akan memungkinkan Anda untuk lebih memanfaatkan pengubah akses Java. Hal ini memungkinkan Anda untuk mendefinisikan antarmuka ke dalam subsistem dengan lebih jelas daripada ke dalam lapisan sistem. Jadi jika Anda memiliki subsistem pesanan yang ingin Anda persisten secara transparan, secara teori Anda tidak boleh membiarkan hal lain tahu bahwa itu persisten dengan tidak harus membuat antarmuka publik ke kelas persistensi di lapisan dao dan sebagai gantinya mengemas kelas dao di dengan hanya kelas-kelas yang ditangani. Jelas, jika Anda ingin mengekspos fungsionalitas ini, Anda dapat menyediakan antarmuka untuk itu atau membuatnya menjadi publik. Sepertinya Anda kehilangan banyak ini dengan memiliki potongan vertikal fitur sistem Anda yang dibagi menjadi beberapa paket.

   4. Saya kira satu kelemahan yang dapat saya lihat adalah hal itu membuat merobek lapisan sedikit lebih sulit. Alih-alih hanya menghapus atau mengganti nama sebuah paket dan kemudian menjatuhkan yang baru dengan teknologi alternatif, Anda harus masuk dan mengubah semua kelas di semua paket. Namun, saya tidak melihat ini masalah besar. Mungkin karena kurangnya pengalaman, tetapi saya harus membayangkan bahwa berapa kali Anda menukar teknologi tidak ada artinya dibandingkan dengan berapa kali Anda masuk dan mengedit potongan fitur vertikal dalam sistem Anda.

Jadi saya kira pertanyaannya akan keluar kepada Anda, bagaimana Anda memberi nama paket Anda dan mengapa? Harap dipahami bahwa saya tidak selalu berpikir bahwa saya telah tersandung pada angsa emas atau sesuatu di sini. Saya cukup baru dalam semua ini dengan sebagian besar pengalaman akademis. Namun, saya tidak bisa menemukan lubang dalam alasan saya jadi saya berharap Anda semua bisa sehingga saya bisa melanjutkan.

Untuk desain paket, pertama saya bagi berdasarkan lapisan, kemudian dengan beberapa fungsi lainnya.

Ada beberapa aturan tambahan:

1. lapisan ditumpuk dari yang paling umum (bawah) hingga paling spesifik (atas)
2. setiap lapisan memiliki antarmuka publik (abstraksi)
3. sebuah lapisan hanya dapat bergantung pada antarmuka publik dari lapisan lain (enkapsulasi)
4. sebuah lapisan hanya dapat bergantung pada lapisan yang lebih umum (ketergantungan dari atas ke bawah)
5. sebuah lapisan sebaiknya bergantung pada lapisan yang berada tepat di bawahnya

Jadi, untuk aplikasi web misalnya, Anda dapat memiliki lapisan berikut di tingkat aplikasi Anda (dari atas ke bawah):

• lapisan presentasi: menghasilkan UI yang akan ditampilkan di tingkat klien
• application layer: berisi logika yang dikhususkan untuk aplikasi, stateful
• lapisan layanan: mengelompokkan fungsionalitas berdasarkan domain, tanpa kewarganegaraan
• lapisan integrasi: menyediakan akses ke tingkat backend (db, jms, email, ...)

Untuk tata letak paket yang dihasilkan, berikut beberapa aturan tambahan:

• akar dari setiap nama paket adalah <prefix.company>.<appname>.<layer>
• antarmuka lapisan selanjutnya dibagi berdasarkan fungsionalitas: <root>.<logic>
• implementasi privat sebuah layer diawali dengan privat: <root>.private

Berikut adalah contoh tata letak.

Lapisan presentasi dibagi dengan teknologi tampilan, dan secara opsional oleh (kelompok) aplikasi.

com.company.appname.presentation.internal
com.company.appname.presentation.springmvc.product
com.company.appname.presentation.servlet
...

Lapisan aplikasi dibagi menjadi kasus penggunaan.

com.company.appname.application.lookupproduct
com.company.appname.application.internal.lookupproduct
com.company.appname.application.editclient
com.company.appname.application.internal.editclient
...

Lapisan layanan dibagi menjadi domain bisnis, dipengaruhi oleh logika domain di tingkat backend.

com.company.appname.service.clientservice
com.company.appname.service.internal.jmsclientservice
com.company.appname.service.internal.xmlclientservice
com.company.appname.service.productservice
...

Lapisan integrasi dibagi menjadi 'teknologi' dan objek akses.

com.company.appname.integration.jmsgateway
com.company.appname.integration.internal.mqjmsgateway
com.company.appname.integration.productdao
com.company.appname.integration.internal.dbproductdao
com.company.appname.integration.internal.mockproductdao
...

Keuntungan dari memisahkan paket seperti ini adalah lebih mudah untuk mengelola kompleksitas, dan meningkatkan testability dan reusability. Meskipun sepertinya banyak overhead, menurut pengalaman saya itu sebenarnya sangat alami dan semua orang yang mengerjakan struktur ini (atau serupa) mengambilnya dalam hitungan hari.

Mengapa menurut saya pendekatan vertikal tidak begitu baik?

Dalam model berlapis, beberapa modul tingkat tinggi yang berbeda dapat menggunakan modul tingkat yang lebih rendah yang sama. Misalnya: Anda dapat membangun beberapa tampilan untuk aplikasi yang sama, beberapa aplikasi dapat menggunakan layanan yang sama, beberapa layanan dapat menggunakan gateway yang sama. Triknya di sini adalah ketika berpindah melalui lapisan, tingkat fungsionalitas berubah. Modul di lapisan yang lebih spesifik tidak memetakan 1-1 pada modul dari lapisan yang lebih umum, karena tingkat fungsionalitas yang mereka ekspresikan tidak memetakan 1-1.

Saat Anda menggunakan pendekatan vertikal untuk desain paket, yaitu Anda membagi berdasarkan fungsionalitas terlebih dahulu, kemudian Anda memaksa semua blok penyusun dengan tingkat fungsionalitas yang berbeda ke dalam 'jaket fungsionalitas' yang sama. Anda mungkin merancang modul umum Anda untuk yang lebih spesifik. Tetapi ini melanggar prinsip penting bahwa lapisan yang lebih umum seharusnya tidak mengetahui tentang lapisan yang lebih spesifik. Misalnya, lapisan layanan tidak boleh dimodelkan setelah konsep dari lapisan aplikasi.

Saya menemukan diri saya berpegang teguh pada prinsip desain paket Paman Bob . Singkatnya, kelas-kelas yang akan digunakan kembali bersama-sama dan diubah bersama-sama (untuk alasan yang sama, misalnya perubahan ketergantungan atau perubahan kerangka kerja) harus diletakkan dalam paket yang sama. IMO, kerusakan fungsional akan memiliki peluang yang lebih baik untuk mencapai tujuan ini daripada kerusakan vertikal / khusus bisnis di sebagian besar aplikasi.

Misalnya, potongan horizontal objek domain dapat digunakan kembali oleh berbagai jenis front-end atau bahkan aplikasi dan potongan horizontal front-end web kemungkinan besar akan berubah bersama ketika kerangka web yang mendasarinya perlu diubah. Di sisi lain, mudah untuk membayangkan efek riak dari perubahan ini di banyak paket jika kelas di berbagai area fungsional dikelompokkan dalam paket tersebut.

Jelas, tidak semua jenis perangkat lunak itu sama dan perincian vertikal mungkin masuk akal (dalam hal mencapai tujuan dapat digunakan kembali dan dapat ditutup-untuk-berubah) dalam proyek tertentu.

Biasanya ada kedua tingkat pembagian. Dari atas, ada unit penyebaran. Ini dinamai 'secara logis' (dalam istilah Anda, pikirkan fitur Eclipse). Di dalam unit penerapan, Anda memiliki divisi fungsional paket (pikirkan plugin Eclipse).

Misalnya, fitur adalah com.feature, dan terdiri dari com.feature.client, com.feature.coredan com.feature.uiplugin. Di dalam plugin, saya hanya memiliki sedikit pembagian ke paket lain, meskipun itu juga tidak biasa.

Pembaruan: Btw, ada pembicaraan bagus oleh Juergen Hoeller tentang organisasi kode di InfoQ: http://www.infoq.com/presentations/code-organization-large-projects . Juergen adalah salah satu arsitek Spring, dan tahu banyak tentang hal ini.

Sebagian besar proyek java yang saya kerjakan mengiris paket java secara fungsional terlebih dahulu, lalu secara logis.

Biasanya bagian-bagiannya cukup besar sehingga dipecah menjadi artefak bangunan yang terpisah, di mana Anda dapat menempatkan fungsionalitas inti ke dalam satu toples, apis ke yang lain, barang frontend web ke dalam warfile, dll.

Paket harus dikompilasi dan didistribusikan sebagai satu kesatuan. Saat mempertimbangkan kelas apa yang termasuk dalam sebuah paket, salah satu kriteria utamanya adalah ketergantungannya. Apa paket lain (termasuk pustaka pihak ketiga) yang bergantung pada kelas ini. Sistem yang terorganisir dengan baik akan mengelompokkan kelas dengan dependensi serupa dalam sebuah paket. Ini membatasi dampak perubahan dalam satu pustaka, karena hanya beberapa paket yang terdefinisi dengan baik yang akan bergantung padanya.

Sepertinya logis, sistem vertikal Anda mungkin cenderung "mencoreng" ketergantungan di sebagian besar paket. Artinya, jika setiap fitur dikemas sebagai potongan vertikal, setiap paket akan bergantung pada setiap pustaka pihak ketiga yang Anda gunakan. Setiap perubahan pada perpustakaan kemungkinan besar akan mempengaruhi seluruh sistem Anda.

Saya pribadi lebih suka mengelompokkan kelas secara logis kemudian di dalamnya termasuk sub-paket untuk setiap partisipasi fungsional.

Tujuan pengemasan

Bagaimanapun, paket adalah tentang pengelompokan hal-hal bersama - gagasan menjadi kelas terkait hidup berdekatan satu sama lain. Jika mereka tinggal di paket yang sama, mereka dapat memanfaatkan paket pribadi untuk membatasi visibilitas. Masalahnya adalah menggabungkan semua tampilan dan ketekunan Anda ke dalam satu paket dapat menyebabkan banyak kelas tercampur menjadi satu paket. Hal selanjutnya yang perlu dilakukan adalah membuat view, persistance, sub paket util dan kelas refactor yang sesuai. Sayangnya protected and package private scoping tidak mendukung konsep paket dan subpaket saat ini karena ini akan membantu dalam menegakkan aturan visibilitas tersebut.

Saya sekarang melihat nilai dalam pemisahan melalui fungsionalitas karena nilai apa yang ada untuk mengelompokkan semua hal yang terkait tampilan. Hal-hal dalam strategi penamaan ini menjadi terputus dengan beberapa kelas dalam tampilan sementara yang lain dalam ketekunan dan seterusnya.

Contoh struktur kemasan logis saya

Untuk tujuan ilustrasi, mari beri nama dua modul - saya akan menggunakan modul nama sebagai konsep yang mengelompokkan kelas di bawah cabang tertentu dari pohon pacckage.

Keuntungan

Seorang klien yang menggunakan Banana.store.BananaStore hanya dihadapkan pada fungsionalitas yang ingin kami sediakan. Versi hibernate adalah detail implementasi yang tidak perlu mereka ketahui, mereka juga tidak harus melihat class ini saat menambahkan clutter ke operasi penyimpanan.

Keuntungan Logis v Fungsional lainnya

Semakin jauh ke root semakin luas cakupannya dan hal-hal yang termasuk dalam satu paket mulai menunjukkan semakin banyak ketergantungan pada hal-hal yang termasuk dalam modulnya. Jika seseorang harus memeriksa, misalnya modul "banana", sebagian besar dependensi akan dibatasi di dalam modul itu. Nyatanya kebanyakan pembantu di bawah "banana" tidak akan dirujuk sama sekali di luar cakupan paket ini.

Mengapa fungsionalitas?

Nilai apa yang dicapai seseorang dengan menggabungkan berbagai hal berdasarkan fungsionalitas. Sebagian besar kelas dalam kasus seperti itu tidak bergantung satu sama lain dengan sedikit atau tidak perlu memanfaatkan metode atau kelas privat paket. Memfaktorkannya kembali menjadi sub-paket mereka sendiri tidak banyak berguna tetapi membantu mengurangi kekacauan.

Pengembang mengubah sistem

Ketika pengembang ditugaskan untuk membuat perubahan yang lebih dari sepele, tampaknya konyol bahwa mereka memiliki potensi perubahan yang menyertakan file dari semua area pohon paket. Dengan pendekatan terstruktur yang logis, perubahan mereka lebih lokal dalam bagian yang sama dari pohon paket yang sepertinya benar.

Baik pendekatan fungsional (arsitektural) dan logis (fitur) untuk pengemasan memiliki tempat. Banyak contoh aplikasi (yang ditemukan di buku teks dll.) Mengikuti pendekatan fungsional menempatkan presentasi, layanan bisnis, pemetaan data, dan lapisan arsitektur lainnya ke dalam paket terpisah. Dalam aplikasi contoh, setiap paket seringkali hanya memiliki sedikit atau hanya satu kelas.

Pendekatan awal ini baik-baik saja karena contoh yang dibuat-buat sering berfungsi untuk: 1) secara konseptual memetakan arsitektur kerangka kerja yang disajikan, 2) dilakukan dengan satu tujuan logis (misalnya menambah / menghapus / memperbarui / menghapus hewan peliharaan dari klinik) . Masalahnya banyak pembaca yang menganggap ini sebagai standar yang tidak ada batasnya.

Saat aplikasi "bisnis" berkembang untuk menyertakan lebih banyak fitur, mengikuti pendekatan fungsional menjadi beban. Meskipun saya tahu di mana harus mencari tipe berdasarkan layer arsitektur (misalnya pengontrol web di bawah paket "web" atau "ui", dll.), Mengembangkan fitur logis tunggal mulai membutuhkan lompatan bolak-balik di antara banyak paket. Ini rumit, paling tidak, tapi lebih buruk dari itu.

Karena jenis yang terkait secara logis tidak dikemas bersama, API dipublikasikan secara berlebihan; interaksi antara tipe yang terkait secara logis dipaksa menjadi 'publik' sehingga tipe dapat mengimpor dan berinteraksi satu sama lain (kemampuan untuk meminimalkan ke default / visibilitas paket hilang).

Jika saya membangun perpustakaan kerangka kerja, tentu saja paket saya akan mengikuti pendekatan pengemasan fungsional / arsitektural. Konsumen API saya bahkan mungkin menghargai bahwa pernyataan impor mereka berisi paket intuitif yang diberi nama sesuai dengan arsitekturnya.

Sebaliknya, saat membangun aplikasi bisnis saya akan mengemas berdasarkan fitur. Saya tidak memiliki masalah dalam menempatkan Widget, WidgetService, dan WidgetController dalam paket " com.myorg.widget. " Yang sama dan kemudian memanfaatkan visibilitas default (dan memiliki lebih sedikit pernyataan impor serta dependensi antar-paket).

Namun, ada kasus yang saling silang. Jika WidgetService saya digunakan oleh banyak domain logis (fitur), saya mungkin membuat paket " com.myorg.common.service. ". Ada juga peluang bagus bahwa saya membuat kelas dengan maksud agar dapat digunakan kembali di seluruh fitur dan berakhir dengan paket seperti " com.myorg.common.ui.helpers. " Dan " com.myorg.common.util. ". Saya bahkan mungkin akhirnya memindahkan semua kelas "umum" ini kemudian dalam proyek terpisah dan memasukkannya ke dalam aplikasi bisnis saya sebagai ketergantungan myorg-commons.jar.

Itu tergantung pada granularitas proses logis Anda?

Jika mereka berdiri sendiri, Anda sering memiliki proyek baru untuk mereka di kontrol sumber, bukan paket baru.

Proyek yang saya jalani saat ini salah terhadap pemisahan logis, ada paket untuk aspek jython, paket untuk mesin aturan, paket untuk foo, bar, binglewozzle, dll. Saya sedang mencari pengurai khusus XML / writers untuk setiap modul dalam paket itu, daripada memiliki paket XML (yang telah saya lakukan sebelumnya), meskipun masih akan ada paket XML inti tempat logika bersama digunakan. Namun satu alasan untuk ini adalah bahwa itu mungkin dapat diperluas (plugin) dan karenanya setiap plugin juga perlu menentukan kode XML (atau database, dll), sehingga memusatkan ini dapat menimbulkan masalah di kemudian hari.

Pada akhirnya, tampaknya itulah cara yang paling masuk akal untuk proyek tertentu. Saya pikir mudah untuk mengemas sepanjang garis diagram berlapis proyek yang khas. Anda akan mendapatkan campuran kemasan logis dan fungsional.

Yang dibutuhkan adalah ruang nama yang diberi tag. Pengurai XML untuk beberapa fungsionalitas Jython dapat diberi tag baik Jython maupun XML, daripada harus memilih satu atau yang lain.

Atau mungkin aku goyah.

Saya mencoba merancang struktur paket sedemikian rupa sehingga jika saya menggambar grafik ketergantungan, akan mudah untuk mengikuti dan menggunakan pola yang konsisten, dengan referensi melingkar sesedikit mungkin.

Bagi saya, ini jauh lebih mudah untuk dipertahankan dan divisualisasikan dalam sistem penamaan vertikal daripada horizontal. jika component1.display memiliki referensi ke component2.dataaccess, yang mengeluarkan lebih banyak lonceng peringatan daripada jika display.component1 memiliki referensi ke dataaccess. komponen2.

Tentu saja, komponen yang dibagikan oleh keduanya masuk dalam paketnya sendiri.

Saya benar-benar mengikuti dan mengusulkan organisasi logis ("menurut fitur")! Sebuah paket harus mengikuti konsep "modul" sedekat mungkin. Organisasi fungsional dapat menyebarkan modul ke suatu proyek, menghasilkan enkapsulasi yang lebih sedikit, dan rentan terhadap perubahan dalam detail implementasi.

Mari kita ambil plugin Eclipse sebagai contoh: meletakkan semua tampilan atau tindakan dalam satu paket akan menjadi berantakan. Sebagai gantinya, setiap komponen fitur harus masuk ke paket fitur, atau jika ada banyak, ke subpaket (featureA.handlers, featureA.preferences, dll.)

Tentu saja, masalahnya terletak pada sistem paket hierarkis (yang dimiliki antara lain Java), yang membuat penanganan masalah ortogonal tidak mungkin atau setidaknya sangat sulit - meskipun terjadi di mana-mana!

Saya pribadi akan memilih penamaan fungsional. Alasan singkatnya: ini menghindari duplikasi kode atau mimpi buruk ketergantungan.

Izinkan saya menjelaskan sedikit. Apa yang terjadi jika Anda menggunakan file jar eksternal, dengan pohon paketnya sendiri? Anda secara efektif mengimpor kode (dikompilasi) ke dalam proyek Anda, dan dengannya pohon paket (terpisah secara fungsional). Apakah masuk akal untuk menggunakan dua konvensi penamaan pada saat yang bersamaan? Tidak, kecuali itu disembunyikan dari Anda. Dan ya, jika proyek Anda cukup kecil dan memiliki satu komponen. Tetapi jika Anda memiliki beberapa unit logis, Anda mungkin tidak ingin menerapkan ulang, katakanlah, modul pemuatan file data. Anda ingin membaginya di antara unit logis, tidak memiliki ketergantungan buatan antara unit yang secara logis tidak terkait, dan tidak harus memilih unit mana yang akan Anda gunakan untuk meletakkan alat bersama tersebut.

Saya rasa inilah mengapa penamaan fungsional paling banyak digunakan dalam proyek yang menjangkau, atau dimaksudkan untuk mencapai, ukuran tertentu, dan penamaan logis digunakan dalam konvensi penamaan kelas untuk melacak peran tertentu, jika ada dari setiap kelas dalam a paket.

Saya akan mencoba menanggapi dengan lebih tepat setiap poin Anda tentang penamaan logis.

1. Jika Anda harus memancing di kelas lama untuk mengubah fungsionalitas saat Anda memiliki perubahan rencana, itu pertanda abstraksi yang buruk: Anda harus membangun kelas yang menyediakan fungsionalitas yang terdefinisi dengan baik, yang dapat didefinisikan dalam satu kalimat pendek. Hanya beberapa, kelas tingkat atas yang harus mengumpulkan semua ini untuk mencerminkan kecerdasan bisnis Anda. Dengan cara ini, Anda akan dapat menggunakan lebih banyak kode, memiliki perawatan yang lebih mudah, dokumentasi yang lebih jelas, dan masalah ketergantungan yang lebih sedikit.

2. Itu terutama tergantung pada cara Anda menyelesaikan proyek Anda. Jelas, pandangan logis dan fungsional bersifat ortogonal. Jadi jika Anda menggunakan satu konvensi penamaan, Anda perlu menerapkan yang lain ke nama kelas untuk menjaga beberapa urutan, atau bercabang dari satu konvensi penamaan ke yang lain pada kedalaman tertentu.

3. Pengubah akses adalah cara yang baik untuk mengizinkan kelas lain yang memahami pemrosesan Anda mengakses bagian dalam kelas Anda. Hubungan logis tidak berarti pemahaman tentang batasan algoritmik atau konkurensi. Fungsional mungkin, meski tidak. Saya sangat lelah dengan pengubah akses selain publik dan pribadi, karena mereka sering menyembunyikan kurangnya arsitektur dan abstraksi kelas yang tepat.

4. Dalam proyek besar dan komersial, perubahan teknologi terjadi lebih sering daripada yang Anda kira. Misalnya, saya sudah 3 kali mengganti XML parser, 2 kali teknologi caching, dan 2 kali software geolocalisation. Untung saya telah menyembunyikan semua detail berpasir dalam paket khusus ...

Ini adalah eksperimen yang menarik untuk tidak menggunakan paket sama sekali (kecuali untuk paket root.)

Pertanyaan yang muncul kemudian adalah, kapan dan mengapa masuk akal untuk memperkenalkan paket. Agaknya, jawabannya akan berbeda dari apa yang akan Anda jawab di awal proyek.

Saya berasumsi bahwa pertanyaan Anda muncul sama sekali, karena paket seperti kategori dan terkadang sulit untuk memutuskan salah satunya. Terkadang tag akan lebih bermanfaat jika dikomunikasikan bahwa kelas dapat digunakan dalam banyak konteks.

Dari sudut pandang murni praktis, konstruksi visibilitas java ini memungkinkan kelas dalam paket yang sama dengan metode akses dan properti dengan protecteddan defaultvisibilitas, sertapublic orang-orang. Menggunakan metode non-publik dari lapisan kode yang sama sekali berbeda pasti akan menjadi bau kode yang besar. Jadi saya cenderung menempatkan kelas dari lapisan yang sama ke dalam paket yang sama.

Saya tidak sering menggunakan metode dilindungi atau default ini di tempat lain - kecuali mungkin dalam pengujian unit untuk kelas - tetapi ketika saya melakukannya, itu selalu dari kelas pada lapisan yang sama

Tergantung. Dalam pekerjaan saya, terkadang kami membagi paket berdasarkan fungsi (akses data, analitik) atau berdasarkan kelas aset (kredit, ekuitas, suku bunga). Cukup pilih struktur yang paling nyaman untuk tim Anda.

Dari pengalaman saya, penggunaan kembali menciptakan lebih banyak masalah daripada pemecahan. Dengan prosesor dan memori terbaru & murah, saya lebih suka duplikasi kode daripada mengintegrasikan secara erat untuk digunakan kembali.