Haruskah suatu objek mengetahui ID-nya sendiri?

22

obj.idtampaknya cukup umum dan juga tampaknya berada dalam jangkauan sesuatu yang bisa diketahui objek tentang dirinya sendiri. Saya mendapati diri saya bertanya mengapa objek saya harus tahu idnya sendiri?

Tampaknya tidak punya alasan untuk memilikinya? Salah satu alasan utama keberadaannya adalah mengambilnya, dan repositori saya perlu mengetahuinya, dan karenanya menggunakannya untuk interaksi basis data.

Saya juga pernah mengalami masalah ketika saya ingin membuat serialisasi objek ke JSON untuk API RESTful di mana id sepertinya tidak cocok dengan payload, tetapi hanya URI dan memasukkannya ke objek membuatnya menjadi lebih sulit.

Haruskah suatu objek tahu itu id sendiri? mengapa atau mengapa tidak?

pembaruan : Ketentuan

id: Atribut pengidentifikasi pada suatu objek. dalam hal basis data, kunci pengganti bukan kunci alami.
Objek: Entitas, atau objek unik yang dapat diidentifikasi dalam sistem.

object-oriented object-oriented-design

— xenoterracide
sumber

1

Untuk tetap abstrak, jika tidak ada alasan untuk menyimpan informasi, jangan menyimpannya. Itu hanya membuat sakit kepala.

3

Jika Anda tidak tahu kunci unik suatu objek, bagaimana Anda memperbarui data dalam database atau membiarkan pengguna memilih kejadian dari daftar?

— NoChance

@EmmadKareem yang saya katakan adalah bahwa koleksi (repositori) tahu id, jadi mengapa objek itu sendiri perlu. Jika saya memberikan daftar, saya mungkin akan memberikan koleksi, yang tahu id.

— xenoterracide

Jika Anda tidak menggunakan id yang disimpan dengan objek, dan tidak pernah bermaksud atau ingin menggunakannya, jelas itu tidak diperlukan.

— GrandmasterB

@ GrandmasterB tentu saja Anda menggunakan id, pertanyaannya adalah apakah Anda menyimpan id dalam memori dengan objek, dan mengapa.

— xenoterracide

8

Jawaban Singkat: Termasuk pengidentifikasi objek dalam objek adalah suatu keharusan jika akan dirujuk.

Untuk skenario di mana Anda berencana untuk menggunakan kumpulan objek dan memiliki rencana untuk merujuk objek / entitas individu maka pengidentifikasi harus dimasukkan. Namun, mungkin ada kasus-kasus di mana kunci alami / pengidentifikasi seperti DateTimedapat secara artifisial memenuhi kebutuhan itu.

Selain itu, Anda mungkin memiliki DTO Anda sebagai wadah ringan dari objek Anda, yang dapat melompati / menyertakan pengidentifikasi objek itu sendiri. Sungguh semua pilihan ini benar-benar tergantung pada kasus dan kebutuhan penggunaan bisnis Anda .

Sunting: jika Anda ingin mengidentifikasi objek, Anda harus memiliki pengenal. Pengidentifikasi itu bisa menjadi pengganti pengganti, tanggal-waktu, panduan, dll ... pada dasarnya, apa pun yang mengidentifikasi objek Anda dari orang lain dengan cara yang unik.

— EL Yusubov
sumber

2

mengapa mereka harus dimasukkan ke dalam objek, bukan hanya koleksi (dengan asumsi koleksi adalah semacam kamus)?

— xenoterracide

Maksud saya adalah, jika Anda ingin mengidentifikasi objek Anda, Anda harus memiliki pengenal. bisa berupa Id, tanggal-waktu, dll ... apa pun yang mengidentifikasi objek Anda dari orang lain.

— EL Yusubov

1

yah tentu saja, pertanyaan saya lebih pada mengapa objek itu sendiri perlu menyadari pengidentifikasi itu.

— xenoterracide

untuk mengklarifikasi sedikit maksud saya id pengganti, biasanya hal-hal seperti datetime, atau nomor vin, adalah alami dan dengan demikian bagian dari data, dan tidak disebutkan id(atau setidaknya saya tidak akan)

— xenoterracide

6

Dalam upaya untuk meninggalkan jawaban saya yang abstrak seperti pertanyaan Anda, saya pikir Anda telah benar-benar menjawab pertanyaan Anda sendiri.

Objek harus tahu ID-nya sendiri jika perlu.

Suatu objek seharusnya tidak mengetahui ID-nya (atau bahkan memilikinya) jika tidak perlu.

Seperti yang Anda tunjukkan, ada beberapa kasus di mana objek tidak nyaman atau tidak perlu disimpan atau diketahui apakah ID-nya. Tetapi ada kasus lain di mana lebih mudah bagi objek untuk mengetahui ID-nya. Beri kode objek Anda sesuai dengan penggunaannya.

kasus-kasus apa yang membuatnya nyaman untuk mengetahui id-nya? Saya telah merenungkannya dan berpikir bahwa kebanyakan dari mereka hanya dapat didasarkan pada cara kode itu, mungkin loop for digunakan untuk membuat yang obj.idbertentangan dengan rendering koleksi itu sendiri.

— xenoterracide

1

@xenoterracide - melihat dan memperbarui catatan DB yang tidak sinkron adalah salah satu contohnya. Dalam beberapa kasus, saya tidak akan memiliki informasi yang cukup untuk mengidentifikasi secara unik catatan kecuali ID-nya sehingga masuk akal untuk menyimpan ID dengan objek rekaman.

tetapi apakah itu sebab atau akibat? apakah itu persyaratan? jika repositori / koleksi / datamapper Anda (atau rantai lainnya) bertanggung jawab untuk mempertahankan pembaruan, dan ia tahu id dan dapat meneruskannya ... Saya mencoba memahami apakah ada alasan untuk mengikuti atau jika itu ada di sana karena banyak orang menggunakan dan pola rekaman aktif.

— xenoterracide

@ xenoterracide - dalam kasus yang saya pikirkan, itu jelas merupakan kebutuhan sebab akibat. Untuk beberapa kasus yang pernah saya alami, jauh lebih nyaman untuk menyimpan ID yang terkait dengan objek. Pertanyaan Anda bagus karena menantang asumsi dasar yang dibuat banyak orang. Kita cenderung belajar ketika kita menggali asumsi seperti itu. Di sisi lain, jangan terlalu menganalisis dan pergi ke arah yang berlawanan. Kalau tidak, Anda akan berakhir dengan membuat deklarasi sakral yang sama dengan yang Anda hancurkan pada awalnya.

4

Ini cukup umum untuk memasukkan ID, tetapi juga umum untuk menggunakan kamus, yaitu struktur data di mana setiap objek dikaitkan dengan ID-nya dengan cara yang Anda dapat dengan mudah mengambil objek ini mengetahui ID yang sesuai, tetapi objek tidak tahu saya t.

Misalnya, jika Anda membuat API dengan dua metode:

http://api.example.com/products/

Memuat daftar ID produk.
http://api.example.com/product/452/

Memuat produk ID 452.

Maka Anda tidak perlu mengirim ulang ID 452 dalam respons JSON dari permintaan kedua. Pengguna API sudah mengetahui ID.

— Arseni Mourzenko
sumber

4

Saya pikir ini subjektif dan tergantung pada desain Anda.

Sebagian besar meskipun ini tampaknya merupakan desain yang berasal dari rekaman aktif . Dalam catatan aktif, entitas Anda memiliki metode untuk melakukan operasi basis data dan karenanya juga harus mengetahui pengenal basis datanya.

Saat menggunakan pola lain seperti repositori dengan mapper data, menyimpan data ini di objek menjadi tidak perlu dan mungkin tidak pantas.

Ambil contoh sebuah Personobjek. Saya diberi nama yang mungkin unik atau tidak unik di dalam keluarga. Seiring bertambahnya populasi, nama-nama yang lebih besar tidak lagi unik sehingga kami telah membuat pengidentifikasi pengganti untuk sistem yang semakin besar. Contohnya termasuk: SIM saya, dan nomor jaminan sosial. Saya tidak terlahir untuk diberi id, semua id ini harus dilamar.

Sebagian besar tidak membuat kunci primer yang baik untuk perangkat lunak, karena tidak universal. Setidaknya tidak di luar sistem spesifik mereka, SSN jelas unik, dan konsisten, untuk Administrasi Jaminan Sosial. Karena kami biasanya bukan penyedia informasi ini, Anda tidak akan memanggil mereka idmelainkan data yang mereka wakili, misalnya SSN. Kadang-kadang bahkan berisi objek yang dikomposisikan penuh seperti DriversLicenseyang bisa berisi semua informasi yang dilakukan SIM.

Oleh karena itu, semua id umum adalah kunci pengganti dalam sistem, dan dapat diganti dengan dalam referensi memori, hanya berisi id untuk memudahkan pencarian dan penyimpanan catatan.

Karena sebuah idbukan bagian dari data konseptual, saya ragu bahwa itu (umumnya) termasuk dalam objek, karena tidak berasal dari domain. Sebaliknya itu harus dipertahankan untuk tujuannya yaitu untuk mengidentifikasi objek yang tidak memiliki cara lain untuk mewakili identitas yang unik. Ini bisa dilakukan dalam repositori / koleksi dengan mudah.

Dalam perangkat lunak jika Anda perlu mewakili objek sebagai daftar, atau bertahan, Anda dapat melakukannya dari objek repositori / koleksi, atau objek lain yang terkait dengannya. Saat meneruskan ke Pemeta Data (jika terpisah), Anda bisa lewat .update( id, obj ).

Penafian : Saya belum mencoba membangun sistem yang tidak mengandung id di dalam entitas dan dengan demikian dapat membuktikan bahwa saya salah.

— xenoterracide
sumber

2

Seperti yang dicatat oleh GlenH7 dalam komentar, ini pertanyaan yang bagus, karena menantang apa yang diterima begitu banyak orang. Namun yang saya ambil adalah bahwa meskipun membiarkan id keluar mungkin tampak murni secara konseptual, hal yang pragmatis untuk dilakukan adalah menjaga id dengan objek melintasi sebanyak mungkin lapisan sistem. Biayanya sedikit, tetapi bisa berguna ketika segalanya mulai rusak.

Entitas mungkin tidak perlu tahu idnya, sama seperti seseorang tidak perlu mengetahui nomor identifikasi pribadinya, nomor SIM atau pengenal lain yang mungkin digunakan di lokasi Anda. Anda tentu bisa melakukannya tanpa sebagian besar waktu. Namun bijaksana untuk membawa semacam identifikasi pada Anda, untuk berjaga-jaga.

Hal yang sama dapat dikatakan tentang suatu objek. Terlepas dari seluk-beluk lapisan akses data, objek akhirnya memetakan ke entri database tertentu. Entri ini mungkin hanya dapat diidentifikasi secara unik oleh id objek. Jika demikian, maka saya lebih suka untuk memiliki informasi ini tersedia bagi saya kapan saja, terlepas dari apakah saya men-debug beberapa kode UI, angka yang berderak di lapisan bisnis, repositori itu sendiri atau sistem dependen di seluruh layanan web. Atau apakah saya sedang menelusuri log kesalahan dalam hal ini.

Dalam kasus Anda, jika Anda hanya mengambil data dari db dan mendorongnya melalui layanan web, membiarkan id keluar mungkin merupakan hal yang tepat untuk dilakukan. Saya hanya tidak percaya bahwa itu lebih masuk akal daripada menyimpannya dalam kasus umum.

— scrwtp
sumber

2

Anda benar, Anda tidak perlu menyimpan id di objek, selama Anda hanya perlu mengetahuinya dalam konteks repositori Anda.

Situasi berubah ketika Anda meneruskan objek ke kode di luar konteks itu, kode yang tidak meminta objek dengan id (dan karena itu belum mengetahuinya), tetapi membutuhkan id untuk tujuan apa pun (mis. Untuk meletakkannya di daftar id yang akan diminta dari repositori nanti, dengan kode lain).

Dalam situasi itu, Anda memiliki dua opsi:

perkenalkan argumen fungsi baru 'id' di seluruh rantai fungsi antara konteks repositori dan fungsi tempat id diperlukan
sertakan id di objek

Dalam sebagian besar kasus ini, menyimpan id di dalam objek akan menjadi solusi yang lebih baik. Ini juga akan mengurangi perubahan kode ketika id diperlukan di tempat-tempat yang tidak terduga, ditambah lagi mungkin membantu dengan debugging pada waktu-waktu tertentu.

Itu sebabnya saya melakukannya ketika saya melakukannya.

— Paul Thomann
sumber