Bagaimana cara menghindari duplikasi struktur data ketika bagian dari aplikasi ditulis dalam bahasa yang berbeda?

Sebagai contoh, katakan Anda sedang menulis aplikasi di Jawa .

Aplikasi Anda berkomunikasi dengan server API yang ditulis dengan Python .

Server Python berkomunikasi dengan database SQL .

Anda juga memiliki situs web untuk aplikasi Anda yang ditulis dalam JavaScript .

Dengan 4 bahasa yang berbeda, mudah untuk akhirnya mengulangi struktur data yang sama 4 kali berbeda.

Misalnya, suatu Usertipe mungkin terlihat seperti ini (kodesemu):

type User {
  integer id;
  string name;
  timestamp birthday;
}

Setiap bagian dari proyek akan membutuhkan semacam representasi User. Bagian Java dan Python akan membutuhkan dua classdeklarasi yang berbeda . Basis data akan membutuhkan Userdeklarasi tabel. Dan situs front end perlu mewakili Userjuga.

Mengulangi tipe ini 4 kali berbeda benar-benar mematahkan prinsip Don't-Repeat-Yourself . Juga ada masalah bahwa jika Userjenisnya diubah maka perubahan ini perlu diulang di setiap bagian proyek yang berbeda.

Saya tahu bahwa pustaka protobuf Google menawarkan semacam solusi untuk masalah ini di mana Anda menulis struktur data menggunakan sintaks khusus, dan kemudian pustaka menghasilkan deklarasi struktur untuk Anda dalam berbagai bahasa pemrograman. Tetapi ini masih tidak berhubungan dengan masalah harus mengulangi logika validasi untuk tipe Anda.

Adakah yang punya saran atau tautan ke buku / posting blog tentang ini?

design-patterns object-oriented-design code-reuse

— Normangorman
sumber

Ini adalah salah satu alasan mengapa banyak orang telah memindahkan semua perkembangannya ke JavaScript. Bekerja pada klien (web, ion untuk seluler, elektron untuk desktop), server (simpul), basis data (MongoDB).

— Paul

Seseorang dapat berbagi struktur data yang sama jika bagian belakang dan depan menggunakan bahasa yang sama. Anda tidak mengulangi diri Anda sendiri jika menggunakan basis kode yang berbeda. Gunakan tooling untuk menghasilkan kelas dari skema xml atau string Json dari platform dev yang berbeda.

— Jon Raynor

Repeating this type 4 different times really breaks the Don't-Repeat-Yourself principle. Tidak, tidak. Anda memiliki 4 sistem berbeda yang melakukan hal berbeda. Anda mengambil KERING terlalu jauh. Menurut pengalaman saya, jenis reusability yang ingin Anda lakukan adalah benih kejahatan, karena memperkenalkan kopling ketat. Itu bahkan lebih buruk daripada mengulangi User4 kali dalam 4 bahasa yang berbeda. Dalam lingkungan terdistribusi, kopling adalah masalah. KERING tidak.

— Laiv

Tidak punya waktu untuk jawaban: Tergantung pada kebutuhan Anda, Anda dapat mencoba merumuskan aturan untuk validasi menggunakan misalnya OWL (jadi buat ontologi). Aturan validasi kemudian menjadi "data" yang dapat digunakan pada titik yang diperlukan. Mengubah aturan kemudian dapat dilakukan di satu tempat sentral.

— Daniel Jour

Jawaban:

Anda tidak. Atau sungguh, Anda seharusnya tidak.

Jika Anda menganggap aplikasi, server dan situs web Anda sebagai konteks yang terpisah, maka masuk akal untuk membuat struktur duplikat. Alasan mengapa itu mungkin hal yang baik:

Strukturnya serupa, tetapi tidak sama. Bahkan jika 90% struktur sama di semua konteks. Ini 10% yang akan memberi Anda sakit kepala hebat.
Pola dan implementasi mungkin berbeda. Ketika bahasa dan kerangka kerja yang berbeda digunakan, itu menjadi terlalu sulit untuk memiliki implementasi yang sama di semua dari mereka
Struktur bersama menjadi ketergantungan, yang perlu dikelola. Memiliki ketergantungan bersama sangat menyulitkan pembangunan, karena perubahan yang hebat dalam satu konteks tidak masuk akal dalam konteks lainnya. Jadi banyak upaya diperlukan untuk mengoordinasikan pengembangan ketergantungan bersama ini
Konteks yang berbeda memiliki penyebaran yang berbeda. Bahkan jika Anda berhasil berbagi struktur data yang sama dan kode validasi yang sama di semua konteks, masih dapat terjadi bahwa versi baru dari satu konteks digunakan sementara yang lain pada versi lama, sehingga situasi di mana ada desinkronisasi dalam versi masih perlu ditangani

Sementara prinsip KERING luar biasa, saya pikir berbagi struktur data di seluruh konteks atau lapisan menciptakan lebih banyak masalah daripada memecahkannya. Terutama jika proyek tumbuh cukup besar sehingga orang yang berbeda bekerja pada konteks yang berbeda.

— Euforia
sumber

Saya pikir @ Euphoric mendaftar beberapa alasan bagus untuk tidak menggandakan kode Anda. Namun, jika Anda harus melakukannya saya akan merekomendasikan menggunakan pembuatan kode.

Temukan bentuk kanonik data

Untuk melakukannya secara efektif, Anda harus terlebih dahulu menemukan apa bentuk kanonik data. Apakah itu skema SQL Anda, atau kelas di program Java Anda?

Turunkan (secara otomatis) bentuk-bentuk lain darinya

Setelah itu, cari cara untuk menghasilkan semua bentuk lain dari yang kanonik. Misalnya, dengan asumsi bentuk kanonik Anda adalah skema SQL, Anda dapat menghasilkan kode JavaScript, Java, dan Python dari yang mudah (SQL mudah diurai dan kandidat yang baik untuk sumber kanonik).

Mengakomodasi perbedaan

Seharusnya mudah untuk menandai bagian dari kode yang dihasilkan sebagai "jangan sentuh" - dengan cara ini Anda akan mengakomodasi perbedaan yang diperlukan antara semua representasi yang berbeda (misalnya: kode khusus yang Anda tulis untuk JS frontend dan Java backend) yang perlu dipertahankan di seluruh regenerasi.
Ambil contoh dari Git; ketika membuka editor untuk membiarkan Anda memasukkan pesan commit file sudah berisi beberapa teks, tetapi memiliki # -------- >8 --------penanda untuk mengetahui di mana Anda berakhir konten, dan di mana yang teks secara otomatis dimulai.

Namun, jika Anda bisa - hindari duplikasi semacam itu. Ini adalah PITA, meskipun sebagian besar kode Anda dibuat secara otomatis.

Jawaban ini adalah sedikit waktu cerita alih-alih "inilah beberapa praktik terbaik" satu - apa yang saya jelaskan adalah apa yang pernah saya lakukan ketika saya memiliki masalah yang sama seperti Anda dan perlu memiliki data yang sama diwakili di berbagai bagian sistem (atau, lebih tepatnya, dalam dua sistem yang berbeda).

— Mael
sumber