Apakah praktik yang baik untuk membungkus set properti terkait ke dalam struct / kelasnya sendiri?


10

Menulis objek Pengguna di Swift, meskipun pertanyaan saya terkait dengan bahasa yang sangat diketik. Pengguna dapat memiliki banyak tautan (FacebookProfile, InstagramProfile, dll). Beberapa pertanyaan tentang ini.

  1. Apakah praktik yang baik untuk membungkus tautan di objek mereka sendiri?
    Pengguna struct {
       var firstName: string
       v lastName: string
       var email: string
       var links: Links
    }
    Tautan struct {
       var facebook: string
       var instagram: string
       var twitter: string 
    }

Atau haruskah mereka longgar? Saya tahu secara teknis kedua cara itu baik-baik saja, tetapi bertanya-tanya apakah ada pendekatan yang disarankan, secara umum - terutama untuk keterbacaan.

struct User { 
   var firstName: string
   var lastName: string
   var email: string
   var facebookLink: string
   var twitterLink: string
   var instagramLink: string
}
  1. Dalam skenario seperti ini, haruskah tautan menjadi koleksi / daftar? Saya pikir itu bukan daftar karena ada sejumlah opsi tautan yang tersedia, dan bukan jumlah yang terus bertambah. Apakah pemikiran saya benar?

  2. Apakah praktik yang baik untuk menempatkan metode jaringan saya di dalam objek Pengguna, seperti getUsers, getUser, updateUser?

Saya tahu ini bisa subjektif, tetapi saya mencoba memahami apa praktik terbaik di sekitar situasi yang sama. Akan menghargai setiap petunjuk.

Jawaban:


30

Anda akan membutuhkan

  • nol hal,
  • satu hal, atau
  • sejumlah hal yang sewenang-wenang.

Saya kaget bahwa desain Anda memperkirakan bahwa jumlah tautan yang dibutuhkan akan selalu tiga dan Anda tahu nama mereka selamanya.

Apa yang saya khotbahkan disebut nol satu aturan tak terhingga . Mungkin tidak jelas pada awalnya, tetapi itu yang memberitahu saya desain Anda tidak toleran di masa depan.

Saya akan merasa berbeda jika ada sesuatu tentang tautan ini yang khusus bagi mereka. Beberapa hal khusus yang saya lakukan berbeda ketika mengakses tautan facebook yang tidak saya lakukan untuk tautan twitter. Itu akan membuat mereka berbeda. Tapi itu tidak ditunjukkan dalam kode ini.

Itu sebabnya saya tidak terganggu oleh string email. Saya tahu itu digunakan dengan cara yang berbeda dengan tautan.

Jadi sampai saya melihat alasan untuk menggunakan tautan ini secara berbeda, saya berada di sisi koleksi tautan.


4
FacebookProfile, InstagramProfile, ...Saya pikir OP sudah menjawab pertanyaan itu. Bahasanya memberi tahu kami bahwa Pengguna mungkin tidak memiliki satu atau beberapa profil yang terkait dengan jejaring sosial. Tetapi programmer di dalam dirinya telah mengubah elemen ini menjadi tautan belaka. Mengapa bukan koleksi Profiles? Saya setuju dengan CandiedOrange. Anda terlalu banyak berasumsi tentang masa depan. Jejaring sosial baru mungkin muncul. Yang sebenarnya mungkin hilang. Pengguna dapat pergi dan datang dari satu jaringan ke yang lain.
Laiv

Ini sebuah dugaan. Katakanlah Anda ingin menggunakan profil ini untuk login sosial. Memiliki profil komponen, kita harus mulai dari mana. Di mana merangkum informasi mengenai otentikasi dan sesi saat ini dengan profil ini. Ini mungkin dianggap YAGNI atau rekayasa berlebihan, tetapi tidak ada artinya untuk dipikirkan, lihat apakah fitur ini mungkin diminta atau apakah mereka dapat memberikan nilai pada aplikasi kita. Jika tidak, buang saja.
Laiv

1
@ Prabhu tergantung pada mengapa Anda membatasi itu. Dugaan saya hanya cocok untuk GUI. Itu baik saja. Tetapi jangan membatasi struktur data karena GUI. GUI berubah karena kemauan. Struktur data mahal untuk diubah. Benar-benar membayar untuk memperbaikinya pertama kali.
candied_orange

2
Itulah intinya. Hanya mengadopsi struktur-struktur yang akan membuat perubahan di masa depan mungkin kurang menyakitkan. Tidak lebih, tidak kurang. Kami, Manisan dan saya mengatakan ini karena kami (saya percaya) telah sering menghadapi situasi serupa dan kami memperkirakan kemungkinan fitur yang rentan terhadap perubahan atau evolusi. Pada akhirnya, Anda lebih dekat dengan proyek dan prospek masa depannya.
Laiv

1
@ Prabhu: Perhatikan bahwa Anda mengajukan pertanyaan tentang praktik yang baik , bukan apakah itu pendekatan paling ringkas untuk skenario spesifik Anda. Saya biasanya di sisi menghindari over-engineering, tetapi biaya pemeliharaan di masa depan (menambah / menghapus tautan, memperbarui definisi kelas entitas, ...) jauh melebihi biaya penerapan koleksi tautan. Jika Anda disebut kolom link1, link2, link3, kebutuhan untuk koleksi akan lebih jelas. Namun, fakta bahwa Anda memberi kolom nama yang lebih bermakna tidak mengubah fakta bahwa itu adalah kumpulan data yang berulang.
Flater

6

Anda hampir jatuh ke dalam perangkap "Saya melihat kemungkinan teknis".

Hanya karena Anda melihat sifat umum di antara item tidak berarti masuk akal untuk menerapkan agregasi pada mereka. Agregasi harus berarti sesuatu. Bukan pada tingkat teknis tetapi di domain masalah Anda.

Mereka semua tautan baik-baik saja, tetapi dalam konteks kelas pengguna, apakah itu berarti apa-apa? Tidak. Ini sama tidak berartinya dengan sub-grup yang menggunakan kelas yang bernama "string" dan "angka".

Masalah dengan hal semacam ini adalah mengaburkan model Anda. Ini memaksa pembaca kode untuk memutuskan yang bermakna dari yang tidak berarti, sebelum memiliki pemahaman penuh tentang domain.

Tidak ada yang pernah berbicara tentang tautan pengguna. Akan berbeda jika Anda akan memanggil SocialNetworkIds agregasi Anda. Karena itu akan benar-benar berarti sesuatu, itu akan menjadi milik Pengguna yang sebenarnya daripada koleksi teknis yang sewenang-wenang.


Apa tepatnya keraguan saya itulah yang mendorong saya untuk mengajukan pertanyaan ini. Satu-satunya hubungan antara tautan yang berbeda adalah bahwa tautan itu mungkin akan ditampilkan bersama di UI. Jadi, dalam hal ini, Anda menyarankan TIDAK untuk menempatkannya di objek yang terpisah, tetapi menyimpannya langsung di bawah objek Pengguna?
Prabhu

1
Saya pikir itu tidak akan membantu dalam kasus ini. Anda belum memiliki masalah yang membenarkan penambahan lapisan kompleksitas. Jika Anda memiliki lebih banyak properti, mungkin ada keuntungan dalam upaya pengelompokan (dengan nama yang tepat untuk grup). Sulit untuk mengatakan apa yang sesuai tanpa konteks. Intinya adalah itu harus membuat segalanya lebih mudah. Memahami dan / atau melanjutkan apa pun langkah Anda selanjutnya dalam proses pengembangan.
Martin Maat

Saya biasanya seperti menghindari over-engineering, tapi saya bertanya-tanya: apakah Anda telah mengatakan hal yang sama jika OP telah bernama ladang link1, link2, link3? Desain struktur data tidak tergantung pada nama bidang, jadi contoh saya setara secara fungsional. Ini masalah futureproofing. YAGNI umumnya akan berlaku, tetapi jika ada, media sosial telah membuktikan dirinya rentan terhadap popularitas dan perubahan viral. Menghindari pembangunan kembali untuk setiap situs media sosial populer baru tampaknya diinginkan. Kalau tidak, Anda berisiko jatuh ke "bidang apa lagi?" jebakan, yang bisa membuat hutang besar.
Flater

1

Secara umum, saya pikir masuk akal untuk memiliki tautannya sendiri structjika Anda cenderung menerapkan operasi yang sama untuk masing-masing, dan terutama jika Anda selalu melakukan operasi yang sama pada mereka semua. Jika mereka untuk tujuan yang tidak terkait dalam aplikasi Anda, maka saya akan membuatnya terpisah. Misalnya, jika mereka adalah beranda pengguna, situs web penyedia asuransi kesehatan mereka, dan tautan ke situs berita favorit mereka, saya mungkin tidak akan mengelompokkan mereka karena mereka tampaknya tidak terkait. Tetapi untuk 3 situs media sosial, sepertinya mereka akan diperlakukan sama di suatu aplikasi, dan karena itu mungkin harus dikelompokkan bersama. Saya akan menggunakan nama yang lebih deskriptif Links. (Jenis tautan apa? Untuk tujuan apa di aplikasi Anda?)

Saya setuju dengan pemikiran Anda tentang # 2. Seperti disebutkan di atas, jika angka itu akan tumbuh atau menjadi variabel, daftar atau koleksi lain akan menjadi pilihan yang baik, tetapi tidak untuk skenario yang telah Anda jelaskan.

Saya tidak akan menempatkan metode jaringan di dalam objek yang menyimpan data yang diambil oleh jaringan. Dari mana data berasal, dan cara mendapatkannya biasanya tidak relevan dengan tujuan utama suatu kelas. Bagaimana jika di masa depan Anda ingin mendapatkan beberapa data dari disk? Atau ingin pengguna memasukkannya? Cukup jauh menyusuri jalan itu dan sebuah Userkelas sederhana harus memiliki kode untuk menangani setiap metode entri dan pengambilan data yang memungkinkan. Buat Userkelas tetap dan pertahankan data saat berada di memori. Segala sesuatu yang lain dapat ditangani oleh kelas yang lebih tepat.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.