Menerapkan kompleksitas menyembunyikan lapisan

Sebagai bagian dari dependensi yang dimiliki proyek yang saya kerjakan, kami menggunakan beberapa layanan inti. Layanan-layanan ini, yang kami tidak bisa lakukan perubahan besar, adalah kekacauan besar. Bergantung pada metode yang kita gunakan, kita perlu mengonversi parameter (dan mengembalikan nilai) ke penyandian, lokal, dan zona waktu yang berbeda.

Karena kami membuat parameter ini di banyak tempat dalam kode kami sendiri, kami melakukan konversi ini di banyak tempat. Beberapa kali di mana kita menghasilkan mereka, sebelum melewati mereka di pihak kita; beberapa kali tepat sebelum memanggil metode dalam layanan inti. Jadi kekacauan menyebar ke seluruh kode kita, dan saya ingin memperkenalkan layer untuk mengisolasinya.

Pertanyaan saya adalah apa pendekatan terbaik untuk itu. Awalnya saya berpikir untuk hanya membuat layanan / metode yang sesuai dengan setiap layanan / metode yang perlu kita gunakan. Metode-metode ini hanya akan melakukan konversi, mendelegasikan ke layanan inti dan melakukan konversi nilai kembali. Tapi sepertinya ini agak sulit.

Kemudian saya berpikir untuk menggunakan anotasi, tetapi saya tidak sepenuhnya yakin bagaimana menggunakannya. Dan seperti yang saya pahami, idealnya saya perlu menjelaskan metode yang dipanggil. Sebagai contoh, saya dapat membuat anotasi dengan parameter @converToUtc, dan melakukan konversi dalam implementasi anotasi. Apakah ini benar? Tentu saja, ini sulit karena ini bukan kode kami dan itu akan memecahkan kode yang saat ini menggunakan metode-metode itu di proyek selain dari kami.

Apa pendekatan terbaik untuk situasi ini?

Apa yang Anda coba lakukan adalah menerapkan pola fasad . Pada dasarnya Anda ingin menempatkan wajah yang lebih sederhana pada kode inti. Anda mungkin ingin membuat satu set kelas yang menyediakan pemetaan 1: 1 untuk setiap kelas inti, lalu gunakan kelas fasad sebagai pengganti kelas inti. Jika layanan inti hanya sekelompok metode di beberapa kelas monolitik besar, maka Anda dapat mempertimbangkan memecahnya berdasarkan domain fungsional (misalnya, otentikasi, akses data, fungsi bisnis, dll.) Dan memiliki fasad yang berbeda untuk setiap domain. Fasad Anda harus menyajikan antarmuka yang masuk akal untuk kode Anda, dan menangani semua pemetaan dan konversi data yang diperlukan untuk berkomunikasi dengan layanan inti.

Masalah yang Anda hadapi adalah masalah umum yang sering kita hadapi dalam Rekayasa Perangkat Lunak: Membuat alat untuk membawanya ke domain masalah khusus kami dengan menggunakan lapisan abstraksi / konversi.

Anda memiliki aplikasi yang memecahkan masalah. Entitas yang dikandungnya, dikelola, dan berinteraksi dengan adalah entitas yang termasuk dalam domain masalah. Mereka semua dinyatakan dalam istilah yang berguna untuk menyelesaikan masalah yang ada, dan mereka "ramah" karena mereka memungkinkan Anda untuk fokus pada penyelesaian masalah daripada membuang-buang waktu dan mencemari kode Anda dengan konversi yang tidak ada hubungannya dengan masalah di tangan.

Selama Anda memiliki semua kode, itu bagus dan bagus; tetapi ketika Anda membawa alat pihak ketiga (pustaka) ke dalam gambar, alat-alat ini kemungkinan besar tidak ditulis untuk bekerja dalam domain masalah Anda, sehingga mereka memerlukan konversi yang sering kali mengganggu, rumit, dan rawan kesalahan.

Apa yang biasanya terjadi adalah bahwa ketidaknyamanan ini kecil, dan kami hanya mengatasi alat yang diberikan kepada kami. Tetapi ketika ketidaknyamanan itu utama, sehingga membuat kehidupan sehari-hari kita jauh lebih sulit, atau bahwa hasil akhirnya lebih rapuh dan lebih rentan kesalahan, maka kita kadang-kadang memperkenalkan lapisan abstraksi / konversi antara kode kita dan alat yang kita gunakan .

Lapisan abstraksi / konversi ini menawarkan layanan ke kode kami yang dinyatakan dalam domain masalah kami, dan mereka mendelegasikannya ke alat pihak ketiga, melakukan semua konversi yang diperlukan di sepanjang jalan. Ketika melakukan hal itu, lapisan-lapisan ini cenderung juga abstrak sebanyak mungkin dari kekhasan alat yang kami gunakan, sehingga secara teori, kami dapat mengganti alat dengan alat yang berbeda dengan memodifikasi hanya lapisan abstraksi / konversi, tanpa perlu memodifikasi logika inti kami.

Mengenai anotasi, saya tidak melihat bagaimana mereka dapat membantu di sini. Pertama-tama, jika Anda tidak memiliki kode sumber antarmuka target, maka Anda tidak dapat menambahkan anotasi ke dalamnya. Tetapi bahkan jika Anda entah bagaimana dapat menambahkan anotasi ke antarmuka target, agar anotasi berfungsi, Anda harus menyematkan beberapa lapisan perantara antara kode Anda dan antarmuka target, yang memotong panggilan, memeriksa anotasi metode target, dan melakukan konversi yang diperlukan. Anda bisa, mungkin, menggunakan Spring Framework atau sesuatu seperti Castle Proxy's Interceptor mekanisme untuk secara ajaib menyematkan lapisan perantara ini antara kode Anda dan perpustakaan, tetapi menurut saya Anda bisa dengan mudah menulis lapisan perantara dengan cara tradisional, memiliki pengetahuan yang mendalam tentang antarmuka target, melakukan konversi dalam kode-keras , busana sederhana, dan juga mengabstraksi antarmuka perpustakaan sesuai dengan kebutuhan Anda.

Pertama-tama, Anda (atau tim Anda) harus menyetujui format "standar" yang akan Anda gunakan dalam kode Anda sendiri. Sebagai contoh:

• Pengkodean: UTF-8
• Lokal: en_UK
• Zona Waktu: UTC

Hanya setelah itu, Anda bisa menulis layer yang akan menyesuaikan nilai-nilai dengan format yang diminta dari dependansi Anda (saya pikir itu tidak sulit).

Seperti yang dikatakan Mike Nakis, saya juga tidak melihat manfaat menggunakan anotasi untuk menyelesaikan masalah ini.