Pertanyaan "Flat lebih baik dari nested" - untuk data serta kode?


Ini Pertanyaan membuat saya berpikir: haruskah kita menerapkan prinsip bahwa "flat lebih baik daripada bersarang" untuk data dan juga kode? Bahkan ketika ada "struktur pohon logis" pada data?

Dalam hal ini, saya kira itu berarti mewakili anak-anak sebagai daftar ID, daripada daftar sebenarnya anak-anak, dengan semua node dalam daftar tunggal:

[ {'id': 4, 'children': ()},
  {'id': 2, 'children': (1, 7)},
  {'id': 1, 'children': (6, 5)},
  {'id': 6, 'children': ()},
  {'id': 5, 'children': ()},
  {'id': 7, 'children': (3,)},
  {'id': 3, 'children': ()} ]

(Saya menggunakan tuple karena saya lebih suka tidak memberikan diri saya fleksibilitas untuk bermutasi objek sampai fleksibilitas yang membuktikan dirinya untuk menjadi berguna dan bermanfaat dengan cara yang jelas. Dalam hal apapun saya tidak akan pernah menggunakan None di sini bukannya urutan kosong, karena ini mempersulit logika, dan "kasus khusus tidak cukup khusus" - di sini, itu tidak istimewa sama sekali.)

Tentunya ini lebih pendek, tetapi struktur pohon dikaburkan. Apakah itu bertentangan "eksplisit lebih baik daripada implisit"?

Secara pribadi saya menemukan bahwa "datar lebih baik daripada bersarang" adalah penerapan terbatas, dan tidak ada di dekat aspek terpenting dari Zen. (Tentu saja saya tidak dapat melakukan banyak hal fungsional-pemrograman yang bagus yang saya lakukan jika saya tidak membiarkan diri saya bersarang secara signifikan.) Saya menduga bahwa masalah dengan "bersarang" adalah bahwa hal itu memerlukan pengalihan konteks ketika Anda memahami informasi. Saya benar-benar berpikir ini lebih merupakan masalah ketika mengikuti logika imperatif daripada untuk mengurai data atau kode gaya fungsional - di mana lebih mudah untuk secara mental menamai blok tersarang, dan mempertimbangkan cara kerjanya secara terpisah dari konteks luar.

Bagaimana menurutmu?


32
2017-12-07 00:06


asal


Jawaban:


Saya tidak akan secara inheren lebih memilih, tetapi lebih suka menggunakan apa pun yang tampaknya paling cocok untuk tugas itu.

Jika strukturnya penting, bersarang membuat hidup menjadi sederhana. Jika Anda secara teratur beroperasi di atas setiap node, struktur datar membuatnya mudah digunakan for node in tree. Tentu saja, jika Anda mendefinisikan kelas Anda sendiri, cukup mudah untuk mengabstraksikannya sehingga kedua opsi itu sederhana; tetapi mungkin lebih sulit untuk digunakan dengan sistem eksternal, seperti mengkonversi ke JSON.


6
2017-12-07 00:41



haruskah kita menerapkan prinsip bahwa "flat lebih baik daripada bersarang" pada data dan juga kode?

Tidak.

Bahkan ketika ada "struktur pohon logis" pada data?

Itu yang "datar lebih baik daripada bersarang" tidak berlaku untuk data. Hanya untuk kode.

... struktur pohon dikaburkan. Apakah itu bertentangan "eksplisit lebih baik daripada implisit"?

Bahkan tidak sebanding. "Pohon datar" adalah implementasi SQL umum karena SQL tidak dapat menangani rekursi tak terbatas dari pohon yang tepat.

Membandingkan Zen of Python (bahasa) dengan desain struktur data tidak masuk akal. Keduanya tidak lebih sebanding daripada dari angka "2" dan membelah bata keju menjadi potongan "2". Satu hal, yang lain adalah tindakan.

Struktur data adalah sesuatu.

Python mendeskripsikan tindakan.


11
2017-12-07 01:07



Ini adalah pertanyaan yang sepenuhnya subjektif. Jawabannya adalah, tergantung."

Itu tergantung pada penggunaan utama data Anda. Jika Anda terus-menerus harus mereferensikan struktur bersarang, maka masuk akal untuk merepresentasikannya seperti itu. Dan jika Anda tidak pernah mereferensikan representasi datar kecuali ketika membangun struktur bersarang, lalu mengapa struktur datar sama sekali?

Representasi "datar" adalah salah satu dasar dari model basis data relasional: setiap jenis data ada dalam tabel hanya untuk jenis itu, dan setiap hubungan di antara item-item tersebut terdapat dalam tabel terpisah. Ini abstraksi yang berguna, tetapi kadang-kadang sulit untuk bekerja dengan kode. Di sisi lain, memproses semua data dari jenis tertentu adalah hal yang sepele.

Pertimbangkan, misalnya, jika saya ingin mencari semua turunan catatan dengan id 2 dalam data contoh Anda. Jika data sudah ada dalam hierarki (yaitu representasi asli adalah struktur "bertingkat"), maka itu sepele untuk mencari id record 2 dan kemudian melintasi anak-anaknya, anak-anak anak-anak, dll.

Tetapi jika representasi asli berurutan karena Anda telah menunjukkannya maka saya harus melewati seluruh kumpulan data untuk membuat struktur hierarkis dan kemudian temukan catatan 2 dan anak-anaknya.

Jadi, seperti yang saya katakan, "itu tergantung."


9
2017-12-07 00:42



"Semuanya harus dibuat sesederhana mungkin, tetapi tidak lebih sederhana." Flat lebih sederhana dari nested. Jika Anda berurusan dengan data dengan relevan bersarang, lalu meratakan mungkin melanggar bagian "tapi tidak mudah". Saya mengambil Zen dari Python bukan untuk mendorong Anda untuk tidak mempersulit hidup Anda dengan bersarang Anda tidak benar-benar perlu, seperti file konfigurasi XML di mana format datar yang lebih sederhana mungkin cukup.


4
2017-12-11 07:22



Apakah itu bertentangan "eksplisit adalah   lebih baik dari implisit "?

Ya, terutama ketika bersikap eksplisit mencegah Anda menembak secara implisit diri Anda di kaki. "Pohon" dalam contoh Anda dapat memiliki beberapa orang tua yang mengaku memiliki anak yang sama. Ia juga dapat memiliki beberapa node root (dan itu: 2 adalah node root; 4 adalah root dan juga simpul daun.)


3
2017-12-07 00:52



Pertanyaan ini tidak dapat dijawab "secara umum" - tidak ada jawaban yang benar.

Untuk contoh khusus ini, saya sebenarnya menyukai struktur pohon yang lebih baik. Tanpa mengetahui apa-apa tentang aplikasi asli, dan hanya melihat strukturnya, hubungan antar item jelas. Dengan struktur datar, saya harus membaca beberapa dokumentasi, atau kode aplikasi untuk "tahu" bahwa tupel anak-anak Anda merujuk ke id.

Struktur pohon mendokumentasikan diri - struktur datar tidak.


3
2017-12-07 00:58