Ini adalah kisah tentang satu bagian JavaScript yang sangat istimewa, bahasa buatan yang
paling banyak digunakan di dunia saat ini (2019).
Artikel ini menyajikan semacam pandangan filosofis tentang Warisan dalam JavaScript, dan saya hanya berani berharap bahwa itu didasarkan pada sumber pengetahuan yang paling mengesankan: hidup itu sendiri dalam semua manifestasinya. Saya tidak tahu apakah ini inspirasi ketika membuat desain rantai prototipe dalam JavaScript.
Tetapi jika demikian, maka itu sangat penting dan kuat sehingga ketika saya mulai memikirkannya, kadang-kadang bahkan menjadi sulit untuk bernapas ...
(semua tautan digarisbawahi )
Saya juga yakin bahwa tidak seorang pun dari kita akan meragukan bahwa
Brendan Ike (Eich) - penulis bahasa pemrograman JavaScript - adalah seorang jenius yang luar biasa! Dan bukan hanya karena dia sering mengulang:
Selalu bertaruh pada JavaScript!
Ayo mulai! Dan titik awal pertama kita adalah Imajinasi, di mana kita pertama-tama mematikan semua prasangka, kelalaian dan efek samping lainnya.
Kami sedang menuju
Back to the Future , era sebelum penciptaan Internet modern di awal 1990-an.
Dari saat
Peretas pertama yang menemukan segala sesuatu yang kami (
karyawan TI ) sekarang
gunakan , kami telah pindah ke sketsa yang mengesankan: tentang perang antara peramban
Netstcape Navigator 2 dan
Internet Explorer 3.
Java baru saja keluar, dan hampir semuanya dari internet modern belum ditemukan atau tidak terbuka. Mungkin saja, seperti saya, di "masa lalu yang indah" Anda masih muda, dan Anda bisa mengingat perasaan keterlibatan yang luar biasa dalam semua kemegahan yang diciptakan tepat di depan mata Anda.
Jadi, Anda memiliki
PC yang sangat kuat pada
Intell Pentium 200 MMX paling modern dengan 32Mb RAM, Windows 3.11 atau bahkan Windows 95 dan Anda mencari masa depan dengan harapan! Dan, tentu saja, kedua
browser juga terpasang. Anda memiliki
Dial-Up , di mana Anda terhubung ke Jaringan untuk sampah baru, juga, untuk belajar atau hanya mengobrol, mengobrol. Meskipun, hei, Anda masih tidak bisa mengobrol langsung di browser, kemungkinan besar Anda menggunakan sistem pengiriman pesan yang tertunda, sesuatu seperti
EMail atau mungkin
UseNet , atau, sangat mungkin, Anda sudah menguasai pengiriman instan melalui
IRC .
Beberapa tahun berlalu dan secara harfiah SEMUA perubahan ... Tiba-tiba Anda menonton animasi kepingan salju di halaman web memberi selamat kepada Anda pada Tahun Baru dan Natal. Tentu saja, Anda tertarik pada cara ini dilakukan, dan Anda menemukan bahasa baru - JavaScript. Karena
HTML bukan hal baru bagi Anda, Anda mulai mempelajari teknologi kerajinan yang memikat ini. Segera Anda menemukan
CSS dan ternyata ini juga penting, karena semuanya sekarang dibuat dari kombinasi ketiganya: HTML, JavaSript dan CSS. Wow
Sekitar waktu yang sama, Anda mungkin melihat beberapa hal hebat di Windows itu sendiri,
CScript dan
HTA muncul di dalamnya, dan bahkan kemudian menjadi mungkin untuk membuat aplikasi desktop penuh secara langsung di JS (dan ini masih berfungsi).
Jadi Anda mulai membuat Web-Server pertama Anda, mungkin di
Perl atau
C ~
C ++ . Mungkin bahkan Anda mulai menggunakan
OS mirip Unix dan melakukannya di
bash . Dan semuanya "berputar-berputar" berkat
Common Gateway Interface (jangan bingung dengan
CGI lainnya).
PHP masih hampir tidak ada, tetapi mungkin Anda akan segera menyukainya.
Era 200x. Anda sekarang melakukan
ASP di
JScript . Ini sangat mirip dengan JavaScript yang berfungsi di dalam halaman web Anda. Ini sangat keren! Anda sedang mempertimbangkan untuk membuat
mesin template Anda sendiri, semacam parodi
XML . Dan kemudian seseorang tiba-tiba memanggil
AJAX semua cara menyenangkan ini untuk
secara dinamis memuat konten yang telah Anda gunakan selama beberapa tahun sekarang. Dan mereka semua sekarang berpikir bahwa hanya ada
XMLHTTPRequest , tetapi Anda ingat bahwa data dapat ditransfer ke
BMP ,
IFrame atau bahkan dengan memasukkan
tag <script> . Dan kemudian seseorang tiba-tiba dengan antusias berbicara tentang
JSON dan betapa berharganya itu, ketika Anda telah mengarahkan data untuk
selamanya dengan sesuatu seperti ini:
document.write("<" + "script src=" + path + ">");
Itu tidak penting
sekarang , tetapi Anda masih ingat
bagaimana ...
Ketika Anda sadar, dari waktu ke waktu Anda mulai menemukan diri Anda bermain-main dengan
Rhino atau
Nashorn dalam upaya untuk memenuhi keinginan pelanggan Java menggunakan
Alfresco atau
Asterisk . Dan Anda telah mendengar tentang munculnya JavaScript di dunia microchip, dan sangat terinspirasi oleh berita ini. Dan tentu saja, sekarang Anda memiliki
jQuery dan
Backbone .
Menyaksikan salju yang turun tahun 2010 yang akan datang, Anda sudah tahu bahwa di dunia Anda semua aturan permainan akan segera berubah, karena "Pemain No. 1" telah memasuki bidang:
Node.js. Dan 10 tahun ke depan Anda akan habiskan dengan mainan baru ini, dan bahkan sekarang, pada tahun 2019, Anda masih tidak bisa mendapatkan cukup dari seberapa kerennya itu.
Secara umum, Anda senang dengan segalanya, semuanya cocok untuk Anda, semua mainan dan permainan di dalamnya menjadi bagian besar dari minat hidup Anda.
Tetapi ada satu pertanyaan kecil yang Anda tanyakan pada diri Anda hari demi hari, malam demi malam selama dua dekade sekarang:Jika Anda harus melakukan ini, bagaimana Anda menjelaskan Empati menggunakan JavaScript?
Anda tahu bahwa salah satu topik paling rumit dalam JavaScript adalah
Prototipe Inheritance dan Prototype Chain . Dan Anda menyukai topik ini, Anda dapat menjelaskan bagaimana semua ini bekerja dan bekerja, hanya karena Anda telah mempelajarinya hampir sejak awal, bahkan sebelum
versi standar pertama kali lahir, dan di mana, seperti yang Anda ingat, ada
4.2 .1 Objek :
ECMAScript mendukung pewarisan berbasis prototipe. Setiap konstruktor memiliki prototipe terkait, dan setiap objek yang dibuat oleh konstruktor tersebut memiliki referensi implisit ke prototipe (disebut prototipe objek) yang terkait dengan konstruktornya. Lebih jauh, sebuah prototipe mungkin memiliki referensi implisit non-nol ke prototipe-nya, dan seterusnya; ini disebut rantai prototipe .
Setiap objek dibuat dengan referensi implisit ke prototipe. Ini disebut rantai pewarisan prototipe, yang dapat Anda teruskan selama Anda suka.Wow ... Dan jika tiba-tiba, seperti saya, Anda mungkin berpikir bahwa ini adalah salah satu penemuan terbesar dalam
Compuer Science , lalu bagaimana Anda akan mengungkapkan efek dari membaca pernyataan ini terhadap Anda?
Mari kita kembali ke awal. Di halaman 1995. Anda adalah Brendan Ike, dan Anda
perlu menciptakan bahasa pemrograman baru. Mungkin Anda menyukai
Lisp atau
Skema , setidaknya beberapa bagian favorit mereka. Dan Anda dihadapkan pada kebutuhan untuk menyelesaikan masalah
Inheritance , karena Anda harus berpura-pura bahwa bahasa tersebut memiliki implementasi
OOP tertentu.
Mari kita berpikir : Anda perlu mencampur semua hal yang Anda suka, mungkin juga beberapa hal yang tidak Anda sukai, dan koktail yang dihasilkan harus cukup baik sehingga tidak ada yang memperhatikan trik sampai ada kebutuhan nyata untuk memahami bagaimana itu. diatur di dalam.
Dan sekarang pertanyaannya adalah:
apa yang akan terjadi pada Warisan?Mari kita kembali ke dunia nyata sejenak. Apa yang kita ketahui tentang Warisan? Beberapa jawaban yang jelas untuk pertanyaan ini:
- Sebagian besar bentuk kehidupan didasarkan pada Genome . Ini adalah tempat penyimpanan informasi tentang kemungkinan karakteristik dan perilaku yang diduga dari makhluk hidup. Ketika Anda adalah makhluk hidup, Anda membawa bagian dari genom di dalam diri Anda, Anda dapat mendistribusikannya, tetapi Anda menerimanya dari generasi sebelumnya.
- Anda dapat membuat makhluk hidup menggunakan dua teknik: mencampur (genom) dari dua leluhur atau, mungkin, menggunakan kloning monoecious dari salah satu dari mereka. Tentu saja, saat ini kami memiliki teknologi yang memungkinkan pencampuran genom lebih dari satu makhluk, tetapi ini jauh lebih jelas dan tidak begitu alami.
- Faktor waktu itu penting. Jika tidak ada properti yang diwarisi, atau belum, maka satu-satunya jalan keluar kami adalah membuatnya dari awal. Selain itu, ada juga Legacy, yang berpindah kepada makhluk dari leluhurnya bukan melalui genom, tetapi melalui hukum properti, dan ini juga bisa menjadi signifikan.
Kembali ke masa lalu, dan pertanyaan yang tepat yang perlu kita tanyakan pada diri kita adalah sekarang:
Dan, pada kenyataannya, warisan Apa yang ingin kita dapatkan?Bagaimanapun, dalam proses penyelesaian masalah warisan, kita harus setidaknya mengisi celah antara pemrograman dan kehidupan nyata, jika tidak, secara umum, kita tidak akan memiliki hak untuk menyebutnya Warisan.
Sekarang mari kita selesaikan sendiri: kita berada di tahun 1995-an, dan kita memiliki PC yang kuat dengan hanya 32 megabita RAM, dan kita sedang mencoba membuat bahasa yang ditafsirkan, jadi kita harus merawat memori ini dengan cermat. Setiap bagian data, terutama
objek String , menghabiskan banyak memori, dan kita harus dapat mendeklarasikan bagian ini hanya sekali, dan jika memungkinkan di masa depan selalu gunakan hanya pointer ke area memori yang ditempati oleh bagian ini.
Kami meringkas: pertanyaan yang sangat sulit.Ada pendapat populer: "
JavaScript dibuat dari objek ." Dengan menggunakan hal-hal sepele ini, kita dapat dengan mudah menjawab pertanyaan "
dari apa " untuk diwarisi dan "
apa ": dari Objek ke Objek. Demi masalah menghemat memori, ternyata semua data harus disimpan dalam objek-objek ini, dan semua tautan data ini juga harus disimpan dalam properti Warisan dari objek-objek ini. Mungkin sekarang sudah jelas mengapa pada tahun 1995 kami benar-benar perlu membuat Desain berdasarkan rantai prototipe: ini menghemat memori selama mungkin! Dan secara umum, saya pikir ini masih bisa menjadi aspek yang sangat penting.
Berdasarkan desain yang ditunjukkan dan pendapat "
semuanya adalah Obyek ", kita dapat mencoba mengkloning sesuatu seperti itu. Tapi apa kloning di sini sekarang? Saya pikir bahwa mengikuti persyaratan persyaratan kami, kami dapat mengasumsikan sesuatu seperti
Structural atau Surface Copy , dalam sesuatu yang mirip dengan pendahulu
Object.assign modern.
Mari kita laksanakan salinan struktural sederhana pada 1995 dengan
for (var i in) {} , karena standar
sudah mengizinkan ini :
Seperti yang Anda lihat, pendekatan ini masih “berhasil”, meskipun secara umum, tentu saja, saya akan merekomendasikan melihat modul
perluasan untuk pemahaman yang lebih terperinci tentang bagaimana membuat kloning dalam JavaScript, tetapi untuk tujuan artikel ini, aplikasi yang konsisten cukup cocok untuk kita. dijelaskan oleh
cloneProps , karena kita bisa menggunakannya di zaman kuno:
- Objek kloning menggunakan Konstruktor: menggunakan konstruktor, buat setidaknya dua klon yang berbeda
- kloning Konstruktor dari Konstruktor: kami menerapkan penggunaan perilaku satu konstruktor dari konstruktor lain
var SomeConstructor = function () { this.a = 'cloned'; }; var AnotherConstructor = function () {
- kloning Konstruktor menggunakan Objek: kita akan menggunakan objek yang sama untuk mengimplementasikan kloning di setidaknya dua konstruktor
var existentObject = { foo : 'bar' }; var SomeConstructor = function () { cloneProps(foo, this); }; var OtherConstructor = function () { cloneProps(foo, this); };
- kloning satu Objek dari Objek lain: gunakan satu objek untuk membuat beberapa klonnya . Tidak ada yang bisa dijelaskan di sini, anggap saja seperti klonProps kami dari contoh pertama di atas.
Dengan kloning, secara umum, semuanya sederhana, seperti yang kita lihat, semuanya jelas dan secara umum, tetapi ...Apakah begitu mudah bagi kita untuk melakukan Warisan Entitas, menggunakan kombinasi dari para pendahulunya?
- Warisan objek menggunakan Konstruktor: ini adalah tujuan utama para desainer, kami hanya akan menunjukkan bagaimana awalnya dirancang .
var existentObject = { foo : 'bar' }; var SomeConstructor = function () {}; SomeConstructor.prototype = existentObject; var inheritedObject = new SomeConstructor();
- Warisan Konstruktor dari Konstruktor lain: tidak diragukan lagi, orang pertama yang memperhatikan ini adalah Genius yang luar biasa. Secara keseluruhan, ini adalah contoh klasik lain dari mana-mana .
var FirstConstructor = function () { this.foo = 'bar'; }; var InheritedConstructor = function () { FirstConstructor.call(this); }; InheritedConstructor.prototype = { bar : 'foo' }; InheritedConstructor.prototype.constructor = FirstConstructor; var inherited = new InheritedConstructor();
mungkin saja menyatakan sesuatu yang canggih, tetapi mengapa
- Warisan dari Konstruktor dari Objek: sekali lagi, kita hanya menggunakan .prototype = objek setiap kali kita membutuhkannya, tidak ada yang perlu dijelaskan, kita selalu perlu menetapkan Constructor.prototype karena seharusnya meletakkan objek di sana, dan dengan tautan implisit kita mendapatkan semua propertinya. .
- Mewarisi Objek dari Objek: hal yang sama. Kami cukup meletakkan objek pertama di Constructor.prototype dan segera setelah kami mengatakan Constructor baru kami akan membuat salinan bawaan di mana akan ada referensi implisit ke properti dari objek pertama kami.
Dan tentu saja, dalam semua situasi ini dengan warisan, kita akan memiliki kesempatan untuk memeriksa menggunakan
instance dari konstruktor mana kita menciptakan objek, meskipun, tentu saja, harus dicatat bahwa
instanceof itu sendiri muncul dalam standar hampir empat tahun kemudian.
Benar, masih ada detail kecil dari paragraf 4.2.1:
dapat melakukan ini selama diperlukan, seperti dikatakan:
dan sebagainya
Baiklah,
mari kita coba membuat warisan benar-benar tak ada habisnya , menggunakan teknologi
dari 1995 .
Sebenarnya, mari kita bayangkan bahwa kita memiliki dua Entitas, dan
Bukan Konstruktor, tetapi objek sederhana. Dan kami ingin mewarisi satu dari yang lain, dan kemudian mungkin dari yang lain, dan dari yang lain, dan seterusnya ...
Tapi bagaimana caranya?
Lihatlah sedikit lebih jauh, lebih dalam.
Jawaban yang benar di sini lagi adalah:
Warisan apa yang perlu kita ciptakan?Lagi pula, kita tidak membutuhkan Entitas ini sendirian. Kami membutuhkan properti mereka: memori yang dikonsumsi data terkait; dan juga, kita mungkin memerlukan beberapa perilaku: metode menggunakan data ini. Dan itu akan sama
jujurnya , jika kita memiliki kesempatan untuk memeriksa di mana dan di mana kita mewarisi dan menggunakan apa. Secara umum, akan sama kerennya jika kita dapat mereproduksi desain inheren pola pewarisan di masa depan, menyiratkan bahwa jika kita mewarisi satu dari yang lain berkali-kali, kita akan selalu mendapatkan hasil yang sama, sesuai dengan apa yang kita tulis (kontrak) . Meskipun masih, itu bisa berguna bagi kita untuk entah bagaimana memperbaiki momen penciptaan, karena entitas "sebelumnya" kita dapat berubah dari waktu ke waktu, dan "ahli waris", memberi mereka rasa hormat dalam hal ini, masih berubah dengan mereka mungkin tidak terlalu mau.
Dan, karena semua kode kita adalah kombinasi dari data dan perilaku, apakah pada umumnya akan menggunakan metode yang sama - menggabungkan data dan presentasi - ketika merancang sistem Warisan?
Bagi saya, semua ini menyerupai apa yang kita lihat ketika mengamati Kehidupan dalam semua bentuknya yang luar biasa. Dari unicellular pertama, ke multiseluler dan keturunan mereka, dan lebih jauh ke Hewan, orang, humanisme dan suku, peradaban, Intelek, dan bentuk buatannya, dan lebih jauh ke Luar Angkasa, ke Galaksi, ke Bintang! dan:
"... Yang perlu kita lakukan adalah memastikan kita terus berbicara ..."
(semua yang perlu kita lakukan adalah melanjutkan komunikasi)Luar biasa dalam perhatiannya, kutipan dari
Stephen Hawking , yang kemudian dipopulerkan dalam karya besar
Pind Floyd ini .
Memprogram bahasa berdasarkan
passing pesan dan konsep
berbasis aliran yang diterapkan melalui API internal yang kuat memungkinkan Anda untuk beralih dari
data sederhana ke abstraksi yang lebih tinggi, deskripsi, dan yang lainnya. Saya pikir ini murni Seni, dan cara kerjanya khususnya dalam struktur JavaScript yang sangat tersembunyi melalui hubungan implisit antara data dalam rantai prototipe.
Bayangkan lagi dua leluhur, mereka berkomunikasi dan pada satu saat emosi dan perasaan mereka menciptakan anak. Anak itu tumbuh, bertemu anak lain, mereka berkomunikasi, dan keturunan berikutnya muncul, dan lebih jauh lagi dan lagi ... Dan kita selalu membutuhkan Dua orang tua, kalau tidak itu tidak alami, itu sudah akan menjadi rekayasa genetika. Dua, tidak lebih dan tidak kurang. Seorang keturunan menerima hal yang sama dengan Warisan mereka, jadi itu sederhana dan dapat dimengerti.
Saya mengerti ini akan terdengar aneh, tapi ya, kami memiliki semua yang kami butuhkan untuk membuat model Warisan ini pada tahun 1995. Dan dasar dari semua ini adalah
4.2.1 Obyek , referensi tersirat melalui prototipe.
Dan itulah tepatnya, menggabungkan
ParentObject dengan
ParentConstructor dengan menetapkan
.prototype dan kemudian
Constructor mungkin akan membuat kita
ChildObject , tentu saja, jika kita mengucapkan kata ajaib "
baru ":
var ParentObject = { foo : 'bar' }; var ParentConstructor = function () {}; ParentConstructor.prototype = ParentObject; var ChildObject = new ParentConstructor();
Kita bisa melihat di sini kedua leluhur kita. Pada saat kami mengucapkan kata ajaib "
baru ", kami meminta mereka mengobrol. Jika mereka tidak ingin berkomunikasi, Life akan berhenti, proses akan jatuh dengan kesalahan, dan
kompiler (juru bahasa) akan memberi tahu kami tentang hal itu.
Tentu saja, ya, tapi kami memang meminta
Pohon Warisan atau membiarkannya menjadi jauh lebih sederhana, setidaknya untuk Pohon
Silsilah . Dan jawabannya masih sama ...
Obyek Anak kita tumbuh, dan itu
menjadi Objek Induk , kemudian bertemu
Obyek Konstruktor baru dan segera setelah kita mengucapkan kata yang diidam-idamkan "
baru " - sihir:
Dan kita dapat terus melakukan ini tanpa batas. Dan saya, mungkin, benar-benar percaya bahwa ini adalah ide utama ketika mengembangkan desain Rantai Prototipe, karena seperti yang kita semua tahu, pendekatan ini menciptakan beberapa masalah yang
sangat rapi tetapi tidak kurang menyenangkan ...
1: Komunitas ... Seperti yang Anda dapat dengan mudah memeriksa diri sendiri, menentukan dalam
.prototype ParentConstructor ' a atau
AnotherConstructor' a adalah
Kontrak Sosial yang sangat serius dan ketat di Suku kita. Ini menciptakan referensi ke properti
ParentObject (
.foo ) untuk Heirs:
ChildObject dan
SequentialChildObject . Dan jika kita menghilangkan indikasi ini, maka tautan ini akan hilang. Jika kita membuat, dan menetapkan kembali referensi ini ke beberapa objek lain, maka ahli waris kita akan langsung mewarisi properti lain. Oleh karena itu, menggabungkan leluhur melalui.
Prototipe , kita mungkin dapat mengatakan bahwa kita menciptakan semacam
sel masyarakat , karena "leluhur" ini dapat mereproduksi banyak keturunan identik setiap kali kita bertanya kepada mereka tentang hal itu menggunakan yang
baru . Dan dengan demikian, setelah menghancurkan "keluarga", kami merusak kualitas keturunan dari keturunannya, drama semacam itu; ^)
Mungkin ini semua pembicaraan tentang
Legacy dalam kode kita, kita harus mengurus ini ketika kita akan membuat kode yang
aman dan
didukung ! Tentu saja, tidak ada
SOLID ,
Prinsip Liskov dan
Desain oleh Kontrak dan
GRASP dibahas pada tahun 1995, tetapi jelas bahwa metodologi ini tidak dibuat "dari awal", semuanya dimulai jauh lebih awal.
2: Keluarga ... Kami dapat dengan mudah memverifikasi bahwa
ParentObject kami dibiarkan sangat sembrono dengan Constructos lainnya. Ini tidak adil, tetapi kita dapat menggunakan banyak Konstruktor seperti yang kita inginkan dalam Warisan ParentObject kita dan dengan demikian menciptakan keluarga sebanyak yang kita suka. Di sisi lain, setiap Konstruktor sangat erat kaitannya dengan ParentObject melalui tugas .prototype, dan jika kita tidak ingin membahayakan ahli waris kita, kita harus menjaga hubungan ini selama mungkin. Kita bisa menyebutnya seni tragedi dalam sejarah suku kita. Meskipun, tentu saja, ini melindungi kita dari Amnesia - kelupaan dari apa yang kita warisi dan dari siapa, dan mengapa pewaris kita mendapatkan
Warisan seperti itu. Dan, memuji
Mnemosyne yang hebat!, Kita dapat dengan mudah menguji
Pohon Rantai Prototipe kita dan menemukan
Artefak dari apa yang kita lakukan salah.
3: Usia tua ... ParentObject dan
Constructor kami tentu saja rentan terhadap kerusakan selama siklus hidup program kami. Kita dapat mencoba untuk mengurus ini, tetapi tidak ada yang aman dari kesalahan. Dan semua perubahan ini bisa membahayakan ahli waris. Kita harus menjaga
kebocoran memori . Tentu saja, kita dapat menghancurkan bagian kode yang tidak perlu dalam runtime dan dengan demikian membebaskan memori yang tidak lagi digunakan dalam
Siklus Hidup kita. Selain itu, kita harus menyingkirkan semua kemungkinan untuk menciptakan
Paradox Sementara dalam rantai prototipe, karena sebenarnya cukup sederhana untuk mewarisi Leluhur dari Keturunannya sendiri. Tapi ini sudah bisa sangat berbahaya, karena teknik menggoda dengan masa lalu dari masa depan dapat membuat tumpukan
Heisenbag sulit untuk direproduksi, terutama jika kita mencoba mengukur sesuatu yang dengan sendirinya dapat berubah seiring waktu.
Kronik Keputusan
Biarkan itu sederhana, jelas dan tidak terlalu berguna, tetapi alih-alih memikirkan tentang Konstruktor dan ParentObject kita sebagai Ibu dan Ayah, mari kita gambarkan mereka sebagai
telur dan ...
serbuk sari . Kemudian, di masa depan, ketika kita membuat
Zygote menggunakan kata berharga "
baru ", itu tidak akan lagi membahayakan imajinasi kita!
Saat kita melakukan ini, kita akan segera menyingkirkan ketiga masalah di atas! Tentu saja, untuk ini kita perlu kemampuan untuk membuat zigot sendiri, yang berarti kita membutuhkan Pabrik Desainer. Dan sekarang sebut saja apa yang Anda suka, ibu, ayah, apa bedanya, karena intinya adalah jika kita akan mengatakan "
baru ", maka kita harus membuat kandang desainer bunga "baru", meletakkan serbuk sari di atasnya dan hanya ini yang akan memungkinkan kita untuk menumbuhkan
Snowdrop "benar" baru di 2020m yang jauh dan bersalju:
var Pollen = { season : 'Spring' };
(dan ya, jangan lupa untuk memeriksa musim dengan tetesan salju ini, kalau tidak serpihan salju akan jatuh atau jatuh, dan tetesan salju akan menjadi bunga musim semi ...)Tentu saja, Kompleksitas Siklusik dari keputusan yang Anda coba buat menggunakan pendekatan ini akan sangat sebanding dengan Riddle Einstein . Oleh karena itu, di sini saya "membuat" perpustakaan , dapat membantu dengan penciptaan rantai desainer dan memoisasi , (catatan editor: yah, takoe, ambil kue dari rak, bla-bla-bla ) ...Dan meskipun saya tidak dapat membuktikannya, pendekatan ini telah cukup berhasil digunakan dari waktu ke waktu selama dua dekade sekarang, jika Anda perlu 146% yakin bahwa semuanya normal dengan warisan. Anda dapat dengan mudah melihat sendiri bahwa itu diuji, direproduksi, dan didukung secara elemen (Ed. Catatan: yeah, sekarang, Anda meninggalkan segalanya dan memastikannya ).Tentu saja, ini bukan keseluruhan cerita, kami hanya menyatakan fakta: JavaScript dirancang cukup baik untuk menggambarkan Grafik Silsilah secara langsung melalui Warisan. Tentu saja, di sini kami tidak secara diam - diam menyentuh topik degradasi Kelas , tetapi saya yakin Anda sendiri dapat dengan mudah mengganti FlowerEggCell dengan FlowerEggCellClass di dalam FlowersFactory: esensi akan tetap sama jika Anda ingin memeriksa bunga Anda melalui contoh Anda akan melihat bahwa mereka semua adalah keturunan dari FlowerEggCell yang Anda referensikan melalui FlowerZygote . Dan tentu saja, sekarang Anda dapat mengubah properti FlowerZygote itu sendiri , karena ini tidak akan membahayakan FlowerFactory itu sendiri , itu akan tetap dapat membuat konstruktor FlowerEggCell atau FlowerEggCellClass lainnya di masa mendatang sesuai dengan desain " referensi " asli yang Anda letakkan di sana.Saya harap artikel ini telah menghilangkan semua keraguan tentang pentingnya kata .protype pada saat Anda melihat null this ,
. call (null ,
. apply (null . bind (null code style
(. .:
Sorrow , , , ).
!
!
V