Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Ruby
Code

AntiPatterns Basics: Rails Models

by
Length:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Ilham Saputra (you can also view the original English article)

Anti-apa? Mungkin terdengar jauh lebih rumit daripada itu. Selama beberapa dekade terakhir, programmer dapat mengidentifikasi pilihan pola "desain" yang berguna yang sering terjadi di seluruh solusi kode mereka. Sambil memecahkan masalah yang sama, mereka mampu "mengklasifikasikan" solusi yang mencegah mereka menemukan kembali roda sepanjang waktu. Penting untuk dicatat bahwa pola-pola ini harus dilihat lebih sebagai penemuan daripada penemuan sekelompok pengembang maju.

Jika ini agak baru bagi Anda dan Anda menganggap diri Anda lebih sebagai pihak pemula dalam semua hal Ruby/Rails, maka yang ini ditulis untuk Anda. Saya pikir itu yang terbaik jika Anda menganggapnya sebagai perampingan cepat ke topik yang jauh lebih dalam yang penguasaannya tidak akan terjadi dalam semalam. Namun demikian, saya sangat percaya bahwa mulai memasuki tahap awal ini akan sangat bermanfaat bagi pemula dan mentor mereka.

AntiPatterns—seperti namanya—mewakili cukup banyak kebalikan dari pola. Mereka adalah penemuan solusi untuk masalah yang harus Anda hindari. Mereka sering mewakili karya pembuat kode yang tidak berpengalaman yang belum tahu apa yang belum mereka ketahui. Lebih buruk lagi, mereka bisa menjadi hasil dari orang malas yang mengabaikan praktik terbaik dan kerangka kerja alat tanpa alasan yang baik—atau mereka pikir mereka tidak membutuhkannya. Apa yang mungkin mereka harapkan dari penghematan waktu pada awalnya dengan menuntaskan solusi yang cepat, malas atau kotor akan menghantui mereka atau penerus yang menyesal dalam siklus hidup proyek.

Jangan meremehkan implikasi dari keputusan buruk ini—mereka akan mengganggu Anda, apa pun yang terjadi.

Topik

  • Fat Models
  • Missing Test Suite
  • Voyeuristic Models
  • Hukum Demeter
  • Spaghetti SQL

Fat Models

Saya yakin Anda mendengar lagu “Fat models, skinny controllers” yang menyanyikan ribuan kali ketika Anda pertama kali memulai dengan Rails. OK, sekarang lupakan itu! Tentu, logika bisnis perlu diselesaikan di lapisan model, tetapi Anda tidak boleh merasa cenderung untuk memasukkan segala sesuatu di sana tanpa alasan hanya untuk menghindari menyeberang garis ke wilayah pengontrol.

Inilah target baru yang harus Anda tuju: “Skinny models, skinny controllers”. Anda mungkin bertanya, “Nah, bagaimana kita mengatur kode untuk mencapai itu—lagipula, ini adalah permainan zero-sum?” Poin bagus! Nama gim ini adalah komposisi, dan Ruby diperlengkapi dengan baik untuk memberi Anda banyak pilihan untuk menghindari obesitas model.

Di sebagian besar (Rails) aplikasi web yang didukung basis data, sebagian besar perhatian dan pekerjaan Anda akan terpusat di sekitar lapisan model—mengingat bahwa Anda bekerja dengan perancang yang kompeten yang mampu mengimplementasikan barang-barang mereka sendiri dalam pandangan, maksud saya. Model Anda secara inheren akan memiliki lebih banyak 'gravitasi' dan menarik lebih banyak kompleksitas.

Pertanyaannya adalah bagaimana Anda ingin mengelola kerumitan itu. Rekaman Aktif pasti memberi Anda banyak tali untuk digantung sendiri sambil membuat hidup Anda sangat mudah. Ini adalah pendekatan yang menggoda untuk merancang lapisan model Anda dengan hanya mengikuti jalur kenyamanan langsung tertinggi. Namun demikian, arsitektur tahan masa depan lebih mempertimbangkan daripada mengolah kelas besar dan memasukkan semuanya ke objek Rekaman Aktif.

Masalah sebenarnya yang Anda hadapi di sini adalah kompleksitas—tidak perlu begitu, saya katakan. Kelas yang mengumpulkan banyak kode menjadi kompleks hanya dengan ukurannya saja. Mereka lebih sulit untuk dipertahankan, sulit untuk diuraikan dan dipahami, dan semakin sulit untuk berubah karena komposisi mereka mungkin kurang decoupling. Model-model ini sering melebihi kapasitas yang direkomendasikan untuk menangani satu tanggung jawab dan agak di mana-mana. Kasus terburuk, mereka menjadi seperti truk sampah, menangani semua sampah yang dengan malas dibuang ke mereka.

Kita bisa melakukan yang lebih baik! Jika Anda berpikir kompleksitas bukan masalah besar—​lagipula, Anda istimewa, pintar, dan semua—pikirkan lagi! Kompleksitas adalah pembunuh proyek berseri yang paling terkenal di luar sana—bukan lingkungan ramah Anda “Pembela Gelap”.

“Model kurus” mencapai satu hal yang dihargai oleh orang-orang lanjut dalam bisnis pengkodean (mungkin lebih banyak profesi daripada kode dan desain) dan apa yang harus kita perjuangkan sepenuhnya—kesederhanaan! Atau setidaknya lebih dari itu, yang merupakan kompromi yang adil jika kompleksitas sulit untuk diberantas.

Alat apa yang ditawarkan Ruby untuk membuat hidup kita lebih mudah dalam hal itu dan biarkan kita mengurangi lemak dari model kita? Sederhana, kelas dan modul lainnya. Anda mengidentifikasi kode yang koheren yang dapat Anda ekstrak ke objek lain dan dengan demikian membangun lapisan model yang terdiri dari agen berukuran cukup yang memiliki tanggung jawab unik dan berbeda.

Pikirkan tentang hal ini sebagai pemain yang berbakat. Dalam kehidupan nyata, orang seperti itu mungkin bisa memperkosa, menghancurkan, menulis lirik dan menghasilkan lagu sendiri. Dalam pemrograman, Anda lebih suka dinamika band—di sini dengan setidaknya empat anggota berbeda—di mana setiap orang bertanggung jawab atas sesedikit mungkin hal. Anda ingin membangun orkestra kelas yang dapat menangani kompleksitas komposer—bukan kelas maestro genius manajemen mikro dari semua perdagangan.

one man band

Mari kita lihat contoh model gemuk dan bermain dengan beberapa pilihan untuk menangani obesitasnya. Contohnya adalah boneka, tentu saja, dan dengan menceritakan sedikit cerita konyol ini saya berharap akan lebih mudah untuk dicerna dan diikuti oleh pemula.

Kami memiliki kelas Spectre yang memiliki terlalu banyak tanggung jawab dan karenanya tidak perlu berkembang. Selain metode ini, saya pikir mudah untuk membayangkan bahwa spesimen semacam itu sudah mengumpulkan banyak hal lain juga—diwakili oleh tiga titik kecil. Spectre sedang dalam perjalanan untuk menjadi kelas dewa. (Peluang cukup rendah untuk merumuskan kalimat seperti itu lagi dalam waktu dekat!)

Spectre mengubah berbagai jenis agen musuh, delegasi membunuh 007, memanggang anggota kabinet Spectre ketika mereka gagal, dan juga mencetak penugasan operasional. Kasus manajemen mikro yang jelas dan jelas merupakan pelanggaran terhadap "Prinsip Tanggung Jawab Tunggal". Metode pribadi juga menumpuk dengan cepat.

Kelas ini tidak perlu tahu sebagian besar hal yang saat ini ada di dalamnya. Kami akan membagi fungsionalitas ini menjadi beberapa kelas dan melihat apakah kerumitan memiliki beberapa kelas/objek sepadan dengan sedot lemak.

Saya pikir bagian terpenting yang harus Anda perhatikan adalah bagaimana kami menggunakan kelas Ruby biasa seperti Interrogator untuk menangani pergantian agen dari berbagai agen. Contoh dunia nyata dapat mewakili konverter yang, misalnya, mengubah dokumen HTML menjadi pdf dan sebaliknya. Jika Anda tidak memerlukan fungsionalitas penuh dari kelas Rekaman Aktif, mengapa menggunakannya jika kelas Ruby sederhana dapat melakukan triknya juga? Sedikit tali untuk digantungkan.

Kelas Spectre meninggalkan bisnis jahat agen beralih ke kelas Interogator dan hanya mendelegasikannya. Yang ini sekarang memiliki tanggung jawab tunggal untuk menyiksa dan mencuci otak agen yang ditangkap.

Sejauh ini baik. Tetapi mengapa kami membuat kelas terpisah untuk setiap agen? Sederhana. Alih-alih hanya secara langsung mengekstraksi berbagai metode belok seperti turn_mi6_agent ke Interogator, kami memberi mereka rumah yang lebih baik di kelas masing-masing.

Sebagai hasilnya, kami dapat menggunakan polimorfisme secara efektif dan tidak peduli dengan kasus individu untuk agen pengganti. Kami hanya memberi tahu agen yang berbeda ini objek untuk berbalik, dan masing-masing dari mereka tahu apa yang harus dilakukan. Interogator tidak perlu mengetahui secara spesifik tentang bagaimana setiap agen berubah.

Karena semua agen ini adalah objek Rekaman Aktif, kami membuat yang generik, EnemyAgent, yang memiliki pengertian umum tentang apa artinya mengubah agen, dan kami merangkum bit itu untuk semua agen di satu tempat dengan mensubklasifikasikan. Kami menggunakan warisan ini dengan memasok metode turn berbagai agen dengan super, dan karena itu kami mendapatkan akses ke bisnis cuci otak dan penyiksaan, tanpa duplikasi. Tanggung jawab tunggal dan tidak ada duplikasi adalah titik awal yang baik untuk melanjutkan.

Kelas Rekaman Aktif lainnya mengambil berbagai tanggung jawab yang tidak perlu diperhatikan Specter. "Nomor Satu" biasanya adalah pemanggangan anggota kabinet Spectre yang gagal sendiri, jadi mengapa tidak membiarkan benda khusus menangani sengatan listrik? Di sisi lain, anggota Spectre yang gagal tahu cara mati sendiri ketika sedang merokok di kursi mereka oleh NumberOne. Operation sekarang mencetak tugasnya sendiri juga—tidak perlu membuang waktu Spectre dengan kacang seperti itu.

Terakhir, membunuh James Bond biasanya dicoba oleh agen di lapangan, jadi kill_james_bond sekarang menjadi metode di SpectreAgent. Goldfinger akan menangani hal itu secara berbeda, tentu saja—harus bermain dengan laser halie itu jika Anda memilikinya, saya kira.

Seperti yang Anda lihat dengan jelas, kami sekarang memiliki sepuluh kelas di mana sebelumnya kami hanya memiliki satu kelas. Bukankah itu terlalu berlebihan? Tentu saja bisa. Ini adalah masalah yang Anda harus bergulat dengan sebagian besar waktu ketika Anda membagi tanggung jawab tersebut. Anda pasti bisa berlebihan. Tetapi melihat ini dari sudut lain mungkin membantu:

  • Sudahkah kita memisahkan masalah? Benar!
  • Apakah kita memiliki kelas yang ringan dan kurus yang lebih cocok untuk menangani tanggung jawab tunggal? Cukup yakin!
  • Apakah kita menceritakan "kisah", apakah kita melukis gambaran yang lebih jelas tentang siapa yang terlibat dan bertanggung jawab atas tindakan tertentu? Saya berharap begitu!
  • Apakah lebih mudah untuk mencerna apa yang dilakukan masing-masing kelas? Tentunya!
  • Sudahkah kita mengurangi jumlah metode pribadi? Ya!
  • Apakah ini mewakili kualitas pemrograman berorientasi objek yang lebih baik? Karena kami menggunakan komposisi dan merujuk pewarisan hanya jika diperlukan untuk mengatur objek ini, Anda bertaruh!
  • Apakah itu terasa lebih bersih? Iya nih!
  • Apakah kita lebih siap untuk mengubah kode kita tanpa membuat berantakan? Tentu saja!
  • Apakah itu sepadan? Apa yang kamu pikirkan?

Saya tidak menyiratkan bahwa pertanyaan-pertanyaan ini perlu diperiksa dari daftar Anda setiap waktu, tetapi ini adalah hal-hal yang mungkin harus Anda mulai tanyakan pada diri sendiri sambil melangsingkan model Anda.

Merancang model kurus bisa jadi sulit, tetapi ini merupakan langkah penting untuk menjaga aplikasi Anda tetap sehat dan gesit. Ini juga bukan satu-satunya cara konstruktif untuk menghadapi model gemuk, tetapi mereka adalah awal yang baik, terutama bagi pemula.

Missing Test Suite

Ini mungkin AntiPattern yang paling jelas. Datang dari sisi yang didorong oleh hal-hal, menyentuh aplikasi yang matang yang tidak memiliki cakupan tes dapat menjadi salah satu pengalaman paling menyakitkan yang harus dihadapi. Jika Anda ingin membenci dunia dan profesi Anda sendiri lebih dari apa pun, cukup habiskan enam bulan untuk proyek semacam itu, dan Anda akan mengetahui seberapa besar potensi kesalahan dalam diri Anda. Bercanda, tentu saja, tetapi saya ragu itu akan membuat Anda lebih bahagia dan Anda ingin melakukannya lagi—selamanya. Mungkin seminggu juga akan berhasil. Saya cukup yakin bahwa kata penyiksaan akan muncul dalam pikiran Anda lebih sering daripada yang Anda pikirkan.

Jika pengujian bukan bagian dari proses Anda sejauh ini dan rasa sakit seperti itu terasa normal untuk pekerjaan Anda, mungkin Anda harus mempertimbangkan bahwa pengujian tidak seburuk itu, juga bukan musuh Anda. Ketika tingkat kegembiraan terkait kode Anda lebih atau kurang terus-menerus di atas nol dan Anda dapat mengubah kode Anda tanpa takut, maka kualitas keseluruhan pekerjaan Anda akan jauh lebih tinggi dibandingkan dengan output yang dinodai oleh kecemasan dan penderitaan.

Apakah saya melebih-lebihkan? Saya benar-benar tidak berpikir begitu! Anda ingin memiliki cakupan tes yang sangat luas, tidak hanya karena itu adalah alat desain yang hebat untuk hanya menulis kode yang benar-benar Anda butuhkan, tetapi juga karena Anda perlu mengubah kode Anda di beberapa titik di masa depan. Anda akan jauh lebih siap untuk terlibat dengan basis kode Anda—dan jauh lebih percaya diri—jika Anda memiliki alat uji yang membantu dan memandu perbaikan, pemeliharaan, dan ekstensi. Mereka pasti akan muncul di ujung jalan, tidak ada keraguan tentang itu.

Ini juga merupakan titik di mana test suite mulai membayarkan putaran kedua dividen, karena peningkatan kecepatan yang Anda dapat dengan aman membuat perubahan kualitas ini tidak dapat dicapai dengan tembakan panjang dalam aplikasi yang dibuat oleh orang-orang yang berpikir menulis tes adalah omong kosong atau terlalu banyak waktu.

Voyeuristic Models

Ini adalah model yang super usil dan ingin mengumpulkan terlalu banyak informasi tentang objek atau model lain. Itu sangat kontras dengan salah satu ide paling mendasar dalam Pemrograman Berorientasi Objek—enkapsulasi. Kami lebih ingin berjuang untuk kelas mandiri dan model yang mengelola urusan internal mereka sendiri sebanyak mungkin. Dalam hal konsep pemrograman, model-model voyeuristik ini pada dasarnya melanggar "Prinsip Pengetahuan Paling Sedikit", alias "Hukum Demeter"-bagaimanapun Anda ingin mengucapkannya.

Hukum Demeter

Mengapa ini menjadi masalah? Ini adalah bentuk duplikasi-yang halus-dan juga mengarah pada kode yang jauh lebih rapuh daripada yang diantisipasi.

Hukum Demeter adalah bau kode yang paling dapat diandalkan yang selalu dapat Anda serang tanpa khawatir tentang kemungkinan kerugian.

Saya kira menyebut ini sebagai "hukum" tidak semewah mungkin pada awalnya. Gali aroma ini, karena Anda akan membutuhkannya dalam proyek Anda. Pada dasarnya menyatakan bahwa dalam hal objek, Anda dapat memanggil metode pada teman objek Anda tetapi tidak pada teman teman Anda.

Ini adalah cara umum untuk menjelaskannya, dan semuanya bermuara pada penggunaan tidak lebih dari satu titik untuk pemanggilan metode Anda. Ngomong-ngomong, itu benar-benar baik untuk menggunakan lebih banyak titik atau panggilan metode ketika Anda berurusan dengan satu objek yang tidak mencoba untuk mencapai lebih jauh dari itu. Sesuatu seperti @weapons.find_by_name('Poison dart').formula baik-baik saja. Pencari terkadang dapat menumpuk beberapa titik. Namun, merangkum mereka dalam metode khusus adalah ide yang bagus.

Hukum Pelanggaran Demeter

Mari kita lihat beberapa contoh buruk dari kelas-kelas di atas:

Untuk menguasainya, berikut beberapa fiksi lainnya:

Pisang, kan? Tidak terlihat bagus, bukan? Seperti yang Anda lihat, metode ini memanggil terlalu banyak ke dalam bisnis objek lain. Konsekuensi negatif yang paling penting dan jelas adalah mengubah sekelompok metode ini memanggil semua tempat jika struktur objek-objek ini perlu diubah—yang pada akhirnya akan terjadi, karena satu-satunya yang konstan dalam pengembangan perangkat lunak adalah perubahan. Selain itu, terlihat sangat jahat, tidak mudah di mata sama sekali. Ketika Anda tidak tahu bahwa ini adalah pendekatan yang bermasalah, Rails memungkinkan Anda menempuh sejauh ini—tanpa berteriak kepada Anda. Banyak tali, ingat?

Jadi apa yang bisa kita lakukan tentang ini? Bagaimanapun, kami ingin mendapatkan informasi itu entah bagaimana. Untuk satu hal kita dapat menyusun objek kita agar sesuai dengan kebutuhan kita, dan kita dapat menggunakan delegasi yang pintar untuk menjaga model kita tetap langsing pada saat yang bersamaan. Mari selami beberapa kode untuk menunjukkan kepada Anda apa yang saya maksud.

Ini jelas merupakan langkah ke arah yang benar. Seperti yang Anda lihat, kami mengemas informasi yang ingin kami peroleh dalam banyak metode pembungkus. Alih-alih menjangkau banyak objek secara langsung, kami mengabstraksi jembatan-jembatan ini dan menyerahkannya kepada masing-masing model untuk berbicara dengan teman-teman mereka tentang informasi yang kami butuhkan.

Kelemahan dari pendekatan ini adalah memiliki semua metode pembungkus tambahan ini. Terkadang tidak masalah, tetapi kami benar-benar ingin menghindari mempertahankan metode ini di banyak tempat jika suatu objek berubah.

Jika memungkinkan, tempat khusus bagi mereka untuk berubah adalah pada objek mereka—dan hanya pada objek mereka. Mencemari benda dengan metode yang tidak ada hubungannya dengan modelnya sendiri juga merupakan sesuatu yang harus diwaspadai karena ini selalu merupakan bahaya potensial untuk mempermudah tanggung jawab tunggal.

Kita bisa melakukan lebih baik dari itu. Jika memungkinkan, mari kita mendelegasikan metode panggilan langsung ke objek mereka yang bertanggung jawab dan mencoba untuk mengurangi metode pembungkus sebanyak yang kita bisa. Rails tahu apa yang kami butuhkan dan memberi kami metode kelas delegate yang berguna untuk memberi tahu teman-teman kami tentang metode apa yang kami butuhkan.

Mari memperbesar sesuatu dari contoh kode sebelumnya dan melihat di mana kita dapat menggunakan delegasi dengan tepat.

Seperti yang Anda lihat, kita dapat menyederhanakan banyak hal menggunakan delegasi metode. Kami menyingkirkan Operation#spectre_member_name dan Operation#spectre_member_number sepenuhnya, dan SpectreAgent tidak perlu memanggil number di spectre_member lagi—number didelegasikan kembali langsung ke kelas "asal" SpectreMember.

Jika ini sedikit membingungkan pada awalnya, bagaimana cara kerjanya? Anda memberi tahu delegasi yang :method_name yang harus didelegasikan to: which :class_name (beberapa nama metode juga boleh) prefix: true yang sebenarnya adalah opsional.

Dalam kasus kami, ini diawali dengan nama kelas berbasis ular dari kelas penerima sebelum nama metode dan memungkinkan kami untuk memanggil operation.spectre_member_name alih-alih operasi.name berpotensi berpotensi ambigu—jika kami belum menggunakan opsi awalan. Ini berfungsi dengan sangat baik dengan asosiasi belongs_to dan has_one.

Namun has_many di sisi lain, musik akan berhenti dan Anda akan mengalami masalah. Asosiasi ini memberi Anda proksi koleksi yang akan melempar NameErrors atau NoMethodErrors kepada Anda saat Anda mendelegasikan metode ke "koleksi" ini.

Spaghetti SQL

Untuk mengakhiri bab ini tentang model AntiPatterns in Rails, saya ingin meluangkan sedikit waktu tentang apa yang harus dihindari ketika SQL terlibat. Asosiasi Rekaman Aktif memberikan opsi yang membuat hidup Anda lebih mudah ketika Anda menyadari apa yang harus Anda hindari. Metode Finder adalah keseluruhan topik sendiri—dan kami tidak akan membahasnya secara mendalam—tetapi saya ingin menyebutkan beberapa teknik umum yang membantu Anda bahkan ketika Anda menulis yang sangat sederhana.

Hal-hal yang harus kita perhatikan terkait dengan sebagian besar dari apa yang telah kita pelajari sejauh ini. Kami ingin memiliki metode yang mengungkapkan niat, sederhana dan cukup masuk akal untuk menemukan hal-hal dalam model kami. Mari selami kode.

Terlihat tidak berbahaya, bukan? Kami hanya mencari sekelompok agen yang memiliki lisensi untuk membunuh halaman ops kami. Pikirkan lagi. Mengapa OperationsController harus menggali internal Agent? Juga, apakah ini benar-benar yang terbaik yang bisa kita lakukan untuk merangkum pencari pada Agent?

Jika Anda berpikir bahwa Anda dapat menambahkan metode kelas seperti Agent.find_licence_to_kill_agents yang merangkum logika finder, Anda pasti melakukan langkah ke arah yang benar—meskipun tidak cukup.

Kita harus lebih terlibat daripada itu. Pertama-tama, ini tidak menggunakan asosiasi untuk keuntungan kita, dan enkapsulasi juga suboptimal. Asosiasi seperti has_many datang dengan manfaat yang dapat kita tambahkan ke array proksi yang kita dapatkan kembali. Kita bisa melakukan ini sebagai gantinya:

Ini bekerja, tentu saja, tetapi juga hanyalah langkah kecil ke arah yang benar. Ya, pengontrolnya sedikit lebih baik, dan kami memanfaatkan asosiasi model dengan baik, tetapi Anda tetap harus curiga mengapa Operation berkaitan dengan implementasi menemukan jenis Agent tertentu. Tanggung jawab ini adalah milik model Agent itu sendiri.

Lingkup bernama sangat berguna dengan itu. Lingkup mendefinisikan metode kelas yang bisa dilalui—sangat penting—untuk model Anda dan karenanya memungkinkan Anda menentukan kueri berguna yang dapat Anda gunakan sebagai pemanggilan metode tambahan di atas asosiasi model Anda. Dua pendekatan berikut untuk pelingkupan Agent acuh tak acuh.

Itu jauh lebih baik. Seandainya sintaks cakupan adalah hal baru bagi Anda, itu hanyalah lambda (sangat buruk)—tidak terlalu penting untuk langsung melihatnya, dan itu adalah cara yang tepat untuk memanggil lingkup sejak Rails 4. Agent kini ada di bertugas mengelola parameter pencarian sendiri, dan asosiasi dapat menyelipkan apa yang perlu mereka temukan.

Pendekatan ini memungkinkan Anda mencapai kueri sebagai panggilan SQL tunggal. Saya pribadi suka menggunakan scope untuk kesederhanaannya. Lingkup juga sangat berguna untuk rantai di dalam metode finder bernama baik-dengan cara itu meningkatkan kemungkinan menggunakan kembali kode dan kode DRY. Katakanlah kita memiliki sesuatu yang sedikit lebih terlibat:

Kita sekarang dapat menggunakan semua ruang lingkup ini untuk membuat kueri yang lebih kompleks.

Tentu, itu berhasil, tetapi saya ingin menyarankan Anda melangkah lebih jauh.

Seperti yang Anda lihat, melalui pendekatan ini kami menuai manfaat enkapsulasi yang tepat, asosiasi model, penggunaan kembali kode, dan penamaan metode yang ekspresif—dan semuanya sambil melakukan query SQL tunggal. Tidak ada lagi kode spageti, keren!

Jika Anda khawatir melanggar Hukum Demeter, Anda akan senang mendengar bahwa karena kami tidak menambahkan titik dengan menjangkau ke dalam model terkait tetapi merantai mereka hanya ke objek mereka sendiri, kami tidak melakukan kejahatan Demeter.

Pikiran terakhir

Dari perspektif pemula, saya pikir Anda telah belajar banyak tentang penanganan yang lebih baik dari Model Rails dan bagaimana memodelkan mereka lebih kuat tanpa menyerukan hangman.

Namun, jangan tertipu dengan berpikir bahwa tidak ada banyak lagi yang dapat dipelajari tentang topik khusus ini. Saya memberi Anda beberapa AntiPattern yang menurut saya pemula dapat dengan mudah memahami dan menangani untuk melindungi diri mereka sejak dini. Jika Anda tidak tahu apa yang tidak Anda ketahui, banyak tali tersedia untuk melingkar di leher Anda.

Meskipun ini adalah awal yang kuat untuk topik ini, tidak hanya ada lebih banyak aspek AntiPatterns dalam model Rails tetapi juga lebih banyak nuansa yang perlu Anda jelajahi juga. Ini adalah dasar-dasarnya—yang sangat esensial dan penting—dan Anda harus merasa puas untuk sementara waktu sehingga Anda belum menunggu sampai nanti dalam karier Anda untuk mengetahuinya.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.