Get best of the week

Model Pemrograman Reaktif Mental untuk Pengawas


Artikel ini ditujukan untuk banyak pembaca yang ingin mengetahui apa itu Pemrograman Reaktif. Tujuan artikel ini adalah untuk membentuk Model Mental Dasar Pemrograman Reaktif (MM RP) Anda tanpa membahas perincian teknis.

Penolakan
( ) — , . , .
, : , . , , .
.

Tapi pertama-tama, mari kita jelaskan apa hubungan model mental dan atasan yang disebutkan dalam judul artikel tentang itu ...

Tentang Model Mental
, , , . , .
, , (. [1], [2])
? , , . (), , , . , , «», «» « » .
, , (), , - ().

Dan ini bosnya ...
. «» «» , : . ( , «» , ).
, «» , , , , , . , . «» «». , , , .
, , , .., () — , , .
, .


Mengapa Pemrograman Reaktif membutuhkan proyek Anda?


Banyak orang yang tidak terbiasa dengan RP awalnya skeptis terhadapnya, mencurigai bahwa ini hanyalah mode kosong, yang ditutupi oleh beberapa kata yang indah. Terutama ketika mereka mengetahui bahwa Anda dapat mengevaluasi RP hanya dengan mencobanya. Dan untuk mencobanya itu mahal, karena ambang masuk yang tinggi. Kami hidup dan hidup dengan OOP, apa yang hilang darinya?
Izinkan saya memperkenalkan sudut pandang saya tentang hal ini.
Pada awal Pemrograman, ketika sebagian besar program ditulis langsung dalam bahasa assembly, konsep kerja utama (elemen dari Model Mental) programmer adalah instruksi, atau perintah bahasa. Beberapa data (primitif) diumpankan ke input perintah atau instruksi. Instruksi memproses dan mengeluarkan beberapa data output. Munculnya bahasa pemrograman prosedural pertama seperti Fortran tidak mengubah esensi masalah ini. Hanya data dan operasi yang dilakukan (sebagai urutan perintah dasar) menjadi lebih rumit.
Seiring waktu, menjadi jelas bahwa konsep ini tidak terlalu konsisten dengan kenyataan di dunia. Mungkin ada banyak data, mereka bisa sulit terstruktur. Baik data dan fungsionalitas di sekitar mereka akan bagus untuk dibagi menjadi beberapa bagian, untuk mengembangkan dan memelihara secara terpisah, dan digunakan bersama.
OOP memecahkan masalah ini dengan banyak cara. Unit Model Mental programmer OOP khas adalah objek dengan data yang disembunyikan (dienkapsulasi) di dalamnya dan antarmuka akses ke data ini sebagai satu set fungsi.
OOP telah memainkan peran besar dalam otomatisasi dan komputerisasi banyak proses manufaktur dan lainnya. Dan seiring dengan ini, kelemahannya terungkap.
Sayangnya, dalam OOP tidak ada konsep proses seperti itu.
Mereka mencoba memperbaiki situasi dengan berbagai cara, berkonsentrasi pada berbagai aspek.
Jadi, Event-Driven Programming [3], Dataflow-programming [4], Stream processing [5] dan beberapa paradigma lain lahir.
Saya akan berani membangkitkan aliran kritik dari para penganut dan para ahli tentang paradigma ini, mencoba menyampaikan dengan kata-kata sederhana esensi umum mereka.
Dengan satu atau lain cara, paradigma ini beroperasi dengan arus informasi. Pada saat yang sama, Event-Driven Programming, seperti namanya, berfokus pada proses kemunculan elemen-elemen aliran informasi, pemrograman Dataflow - pada kontrol aliran (pemisahan, penggabungan, transformasi aliran) dan pemrosesan aliran pada penggunaan sumber daya yang optimal saat memproses aliran.
Pemrograman Reaktif adalah tentang hal yang sama, tetapi dengan fokus pada operasi dasar tertentu untuk membuat, mengelola, dan menggunakan utas. Itu RP menjelaskan bagaimana sistem Anda bereaksi (Bahasa Inggris bereaksi) terhadap elemen-elemen dari arus informasi. Dalam pengertian ini, akan lebih benar dalam bahasa Rusia untuk menggunakan istilah "Pemrograman Reagen" (dari kata "bereaksi") atau "Pemrograman Reaksi" (dari kata "reaksi terhadap sesuatu") jika bukan untuk memotong telinga, dan yang kedua tidak menyebabkan asosiasi yang salah.
Saya berani mengungkapkan pemikiran hasutan lain. Apa yang kita sebut hari ini dalam Bahasa Inggris Pemrograman Reaktif (Pemrograman Reaktif). disebut demikian karena alasan historis dan cenderung mendukung istilah ini sebagai opini mayoritas.
Paradigma ini bisa disebut berbeda. Karena itu, jangan fokus pada nama saat ini, tetapi cobalah untuk memahami esensinya.
Dan meskipun saya akan berbicara tentang RP pada tingkat yang cukup abstrak, saya akan mengutip API perpustakaan RxJS sebagai contoh nyata.
Singkatan RxJS adalah singkatan dari Reactive Extension for JavaScript, ekstensi JavaScript untuk fitur-fitur Pemrograman Reaktif. Ekstensi serupa ada untuk banyak bahasa pemrograman lain, seperti dapat dilihat pada gambar di bawah ini, yang diambil dari [6].
Ekstensi pemrograman reaktif

Mengapa Model Mental RP membutuhkan proyek Anda


Proyek-proyek besar tidak dilakukan sendirian. Anda dapat sering membaca atau mendengar bahwa peserta proyek harus berbicara dalam bahasa yang sama. Pengalaman saya menunjukkan bahwa ini hampir tidak perlu dan mungkin. Tetapi yang diperlukan adalah agar konsep paling dasar dari proyek dinyatakan dan dipahami oleh peserta proyek dengan setepat mungkin. Dalam hal Model Mental (MM), kita dapat mengatakan bahwa MMs tingkat atas harus semirip mungkin.
Tetapi bagaimana mereka bisa serupa jika analis berpikir dalam hal Alur Kerja dan Kasus Penggunaan, arsitek dalam pola, pengembang fungsi dan struktur data, dan penguji dalam skenario pengujian?
Saya tidak mendesak semua spesialis ini untuk mulai berpikir pada saat yang sama dengan kategori-kategori Pemrograman Reaktif, tetapi saya dapat menjanjikan kepada mereka bahwa berkenalan dengan kategori-kategori ini akan menyederhanakan dan meningkatkan efektivitas komunikasi profesional mereka dengan kolega. Ini harus terjadi karena, di satu sisi, RP MM memiliki kekuatan yang diperlukan untuk menggambarkan Alur kerja yang kompleks, dan di sisi lain, RP MM dapat langsung dikonversi ke kode dalam banyak bahasa pemrograman.

Kejutan, bahaya, atau bahwa dalam RP bukan seperti yang biasa kita semua lakukan


Tetapi sebelum kita masuk ke deskripsi tentang apa yang Mental Model Pemrograman Reaktif terdiri dari, berdasarkan pengalaman kita sendiri, saya ingin memperingatkan pembaca tentang apa yang tidak ada di dalamnya. Selain itu, bukan hanya tidak, tetapi harapan perilaku OOP yang sederhana dan dapat dipahami di dunia menyebabkan konsekuensi yang menyedihkan.
Saya melakukan ini bukan untuk mengintimidasi, tetapi lebih untuk membangkitkan minat pembaca.

Perbedaan 1: Alih-alih model kursor, grafik komputasi


Saya berani menyarankan bahwa banyak pembaca, ketika memikirkan tugas berikutnya untuk direalisasikan, memiliki model mental di kepala mereka, yang saya sebut model kursor. Diasumsikan bahwa algoritma langkah-demi-langkah dalam bentuk daftar linier instruksi akan ditemukan untuk memecahkan masalah. Eksekusi algoritma dikurangi menjadi eksekusi langkah-demi-langkah dari instruksi satu demi satu. Anda dapat membayangkan sesuatu seperti pointer ke instruksi yang sedang dijalankan. Setelah instruksi dieksekusi, pointer (kursor) bergerak ke instruksi berikutnya dalam daftar dan mulai dijalankan.
Dalam model ini, urutan perintah ditulis dalam bahasa pemrograman berorientasi objek bersyarat
1. 1 = 2
2. 2 = 3 
3. 3 = 1 + 2
4.  1, 2, 3
5. 1 = 4
6.  1, 2, 3

akan memberikan hasilnya
2 3 5
4 3 5

Model mental kursor kami memprediksi dengan sempurna dan menjelaskan hasil seperti itu. Setelah memproses baris ketiga, nilai X3 diatur dan nilai baru untuk X1 yang ditentukan pada baris 5 tidak dapat mengubahnya.
Dalam dunia RP, tergantung pada interpretasi operasi "+", hasilnya kemungkinan besar adalah ini
2 3 5
4 3 7

Di dunia ini, sebagian besar operasi menghubungkan parameter input satu sama lain, dengan demikian membuat grafik komputasi yang melaluinya perhitungan "didorong" ketika satu atau lebih parameter diubah.

Perbedaan 2: Operasi asinkron


Dalam kerangka model mental kursor perhitungan, operasi selanjutnya tidak dapat dimulai lebih awal dari yang sebelumnya.
Perhatikan contoh berikut. Misalkan fungsi f1 menghitung gaji pokok berdasarkan nilai pengenal pengguna, userId, dan fungsi f2 menghitung bonus berdasarkan userId dan nilai gaji.
Maka perhitungan gaji penuh mungkin terlihat seperti ini
1. X = f1(userId)
2. Y = f2(userId, X)
 X, Y

Misalkan seorang anggota staf memiliki gaji pokok 10.000. dan bonus 1000 unit.
Model mental kursor kami memberi tahu Anda apa yang harus dicetak.
10000 1000

Sayangnya, di dunia RP asinkron, hasilnya mungkin, tergantung pada durasi operasi, menjadi
0 0 
10000 0 
0 1000 
10000 1000

(Saya belum mempertimbangkan pengecualian).
Masalahnya adalah bahwa di dunia asinkron-reaktif, operasi selanjutnya tidak menunggu akhir dari yang sebelumnya, jika itu adalah yang sebelumnya) asinkron.
Untuk menggambarkan hal ini, mari kita lihat beberapa detail penting menggunakan contoh realistis yang ditunjukkan pada gambar di bawah ini.
Gambar menunjukkan waktu eksekusi dari empat instruksi L1, L2, L3 dan L4 yang independen satu sama lain (angka-angka mereka penting bagi kami, bukan ejaan) dalam mode sinkron (bagian atas gambar) dan asinkron (bagian bawah gambar).

Seperti yang kita lihat, dalam kasus pertama, setiap instruksi selanjutnya "menunggu" untuk akhir dari instruksi sebelumnya. Dalam kasus asinkron, semua instruksi mulai dijalankan secara bersamaan. Karena eksekusi paralel dan penggunaan sumber daya, sebagian besar instruksi berjalan dalam mode asinkron lebih lama daripada dalam mode sinkron. Namun, bersama-sama mereka akan mewariskan pekerjaan mereka sebelumnya.
Urutan penyelesaian instruksi di kedua mode juga sangat berbeda. Secara sinkron:
L1, L2, L3, l4
tetapi dalam asinkron:
L3, L2, L1, L4
.

Perbedaan 3: Rantai tidak lengkap (tanpa konsumen) tidak berfungsi sama sekali


Dalam banyak bahasa pemrograman tradisional, adalah umum untuk mengaitkan pemanggilan fungsi atau properti objek dengan titik-titik.
Misalnya, rantai panggilan fungsi JavaScript berikut mengubah kata "good" menjadi "dog":
„good“.split(„“).reverse().join(„“).replace(„oo“, „o“);

Urutan (rantai) bisa panjang. Untuk alasan penggunaan kembali atau kenyamanan, mereka dapat dipotong-potong dan dilakukan sebagian.
Memisahkan rantai dalam RP menjadi dua bagian dan memanggil hanya satu dari mereka biasanya menyebabkan kurangnya hasil, karena hanya rantai penuh (dengan konsumen pada akhirnya) yang dilakukan.

Mengapa semua ini?


Mungkin, banyak pembaca yang telah mengajukan pertanyaan kepada diri mereka sendiri, “Apakah mereka tidak menjadi gila secara kolektif, para programmer yang reaktif ini? Mengapa itu diperlukan, pemrograman seperti itu? "
Saya tidak berasumsi untuk memprediksi apa yang akan dijawab oleh pencipta dan pakar Republik Polandia, tetapi jawaban saya adalah ini: pemrograman seperti itu diperlukan, karena banyak objek di dunia nyata yang berperilaku seperti itu.
Grafik komputasi - inilah yang menjadi dasar dibangunnya Excel, tidak hanya dari para akuntan, tetapi juga manajer proyek yang senang.
Operasi asinkron . Saat Anda membuat kopi atau membuat teh di dapur, apakah Anda berdiri di dapur selama ini dan melihat teko atau teko kopi Anda? Tidak. Perangkat mendidihkan air dan melakukan tugasnya, saat Anda melakukan sesuatu yang lain untuk saat ini.
Rantai operasi lengkap.Coba cabut lampu meja Anda dari stopkontak dan dorong saklar. Lampu tidak menyala karena ini. Objek ini hanya berfungsi jika ada rantai yang lengkap - dari sumber ke konsumen listrik. Dan ada banyak, jika tidak sebagian besar, benda-benda seperti itu di dunia nyata.

Saya ingin meyakinkan Anda, pengetahuan Anda tentang pemrograman tradisional dan kursor MM tidak boleh dibuang ke tempat sampah karena kemunculan RP. Pemrograman reaktif meninggalkan mereka sendiri dan memperluasnya dengan operasi baru pada objek jenis baru. Bagaimana - kita akan membicarakannya nanti.

Ruang Pemrograman Model Mental dan tempat MM RP di dalamnya


Berbicara tentang tempat RP dalam lanskap umum Pemrograman, penulis sering menyebutkan dua dimensi - kompleksitas objek yang diproses dan sinkronisasi / operasi sinkronisasi. Contoh klasifikasi seperti itu dapat ditemukan dalam buku "RxJS in Action" [7], dalam bab "Kapan dan di mana harus menggunakan RxJS".
Dalam klasifikasi ini, dimensi objek dibagi menjadi objek tunggal dan multi-objek: array, daftar, dll. Operasi dibagi menjadi sinkron dan asinkron.
Dengan demikian, klasifikasi ini membagi dunia pemrograman menjadi empat bidang. RP adalah salah satu area ini yang bertanggung jawab untuk memproses multi-objek dengan operasi asinkron.
Saya menemukan klasifikasi ini sangat menarik, tetapi saya ingin melihatnya dari sudut pandang model mental. Tabel di bawah ini menyajikannya.
Nilai dan Objek tunggal, ,
, (Stream)
, (Promise)(Workflow)

Kami berasumsi bahwa model mental instruksi dan kursor tidak memerlukan penjelasan lebih lanjut.
Siklus adalah perpanjangan dari instruksi MM dan kursor karena instruksi tambahan dari siklus atau kembali ke beberapa titik. Ini memungkinkan satu set instruksi pemrosesan untuk satu objek untuk "membungkus" dalam satu lingkaran, dan dengan demikian memproses banyak objek seperti itu. Dalam hal ini, kursor bergerak di dalam siklus seperti pada model sebelumnya, dan setelah mencapai titik transisi, ia akan melompat ke awal atau pemrosesan siklus berhenti jika semua objek diproses.
Jet. Perbedaan antara model mental ini dan yang sebelumnya adalah bahwa kursor yang
menunjuk ke objek yang diproses tetap di tempatnya, dan objek itu sendiri "melindasnya".
Mari kita lihat ini dengan dua contoh. Jika Anda melukis pagar kayu, Anda, dengan analogi dengan model kursor, pergi dari papan ke papan. Tetapi pekerja pada konveyor tetap di tempat dan, dengan analogi dengan model jet, bagian-bagian yang akan diproses sendiri mendekatinya. Objek seperti itu sering disebut dengan istilah Stream Bahasa Inggris, misalnya, dalam bahasa Jawa.
Tiang sinyal. MM ini paling mudah dikaitkan dengan lampu lalu lintas di persimpangan. Objek asinkron secara berkala melakukan polling status variabel publik dan melakukan tindakan tertentu setelah mengubah kondisinya. (Seperti pengemudi di depan lampu lalu lintas)
Menunggu.Metafora yang cocok untuk Model Ekspektasi Mental ini adalah huruf di atas kertas atau Emall yang Anda harapkan saat terakhir kali mendapatkan pekerjaan Anda. Mungkin ada jawaban positif atau negatif. Perilaku Anda setelah menerima surat sangat tergantung pada isinya. Istilah Bahasa Inggris Janji sering digunakan untuk menggambarkan benda-benda semacam ini. Bahwa, dari sudut pandang pengguna adalah harapan, bagi kontraktor yang menyediakan layanan, itu adalah janji.
Seperti yang kita lihat dari deskripsi, gerakan sepanjang setiap dimensi (dari atas ke bawah atau dari kanan ke kiri dalam tabel) berarti perubahan kualitatif dalam Model Mental.
Seperti dapat dilihat dari tabel, jet dan harapan adalah tetangga di sebelah kiri dan di atas sel tenggara yang menarik bagi kita. Apa yang baru dalam Model Mental Arus yang menghuni sel yang menarik bagi kita dibandingkan dengan mereka?

Apa ekstensi itu?


Perluasan Streaming dibandingkan dengan Harapan adalah bahwa informasi yang diharapkan dapat tiba tidak hanya sekali, tetapi dalam banyak bagian. Dalam hal ini, proses dapat berakhir tanpa berakhir. Itu setelah serangkaian porsi sukses, kami akan menerima pemberitahuan kesalahan. Selain itu, versi lain dari informasi ditambahkan - pemberitahuan akhir proses.
Ini berarti, misalnya, adalah mungkin untuk menerima beberapa (tetapi tidak semua) bagian dari informasi yang diharapkan dan (tanpa pesan kesalahan) pesan tentang akhir pemrosesan.
Ingat lagi, dengan Menunggu, kami hanya memiliki dua opsi alternatif untuk informasi yang dihasilkan.
Model Jet Mental sangat cocok untuk memahami, mendiskusikan, dan mengimplementasikan proses mengubah urutan objek dari jenis yang sama. MM Stream memperluasnya dengan aspek-aspek berikut:
  • Mungkin ada banyak jet dan kita bisa menggabungkannya
  • Jet-jet itu mungkin heterogen
  • Kami dapat membagi jet menjadi yang baru sesuai dengan kriteria yang berbeda
  • Kita dapat "menutup" dan / atau mengubahnya menjadi yang baru dalam kerangka satu aliran.

Jadi, kami menentukan tempat MM RP (Streaming) di ruang atau lansekap objek Pemrograman. Sekarang mari kita turunkan pandangan mata burung dan melihat lebih dekat pada Streams dan Model Mental mereka.

Aliran dan fase dari siklus hidup mereka


Sebagai perkiraan pertama, aliran RP dapat dibayangkan sebagai aliran air di pipa air atau aliran listrik. Harus diingat bahwa seperti analogi lainnya, analogi ini memiliki keterbatasan dan tidak selalu dapat diterapkan.
Berbicara tentang aliran, aspek-aspek penting berikut dapat dibedakan:

  1. Setiap utas entah bagaimana muncul
  2. Dia entah bagaimana bergerak menuju konsumen.
  3. Sesuatu terjadi dalam perjalanan dengannya (dia bertransformasi)
  4. Itu dapat dibagi menjadi beberapa aliran atau digabung dengan aliran lain
  5. Konsumen entah bagaimana menggunakan arus, tidak ada lagi.

Aspek-aspek yang tercantum secara bersamaan adalah fase dari siklus hidup elemen individu dari aliran.
Mari kita pertimbangkan mereka secara lebih rinci menggunakan contoh fungsi RxJS.

Pembuatan utas


Streaming dapat dibuat dari elemen pasif seperti array atau daftar objek dalam program Anda, byte, baris file, dll. Sumber aliran semacam ini disebut dingin (walaupun secara teknis ada definisi sumber aliran dingin yang lebih akurat).
Mata air panas yang disebut "menjalani kehidupan mereka sendiri" dan jika Anda tidak terhubung ke mereka pada waktunya, informasi akan hilang. Kategori ini mencakup informasi tentang tindakan pengguna pada komputer, tablet, smartphone, misalnya, informasi tentang penekanan tombol, gerakan mouse, atau menyentuh layar. Juga dalam kategori ini adalah data yang diminta oleh berbagai protokol seperti HTTP, data dari berbagai sensor.
Perlu dicatat bahwa ada yang disebut mata air "hangat". Selain itu, beberapa mata air "panas" dapat "didinginkan", dan "dingin" dapat "dihangatkan". Tetapi Anda harus membaca tentang ini dalam literatur khusus, misalnya, dalam buku [7].
Penting bagi kita untuk mengetahui bahwa semua operasi menciptakan aliran membuat objek dengan tipe yang sama, yang dapat diproses lebih lanjut oleh operasi yang sama, terlepas dari konten. Dalam artikel ini, kami menyebut objek ini aliran. Nama bahasa Inggris yang sesuai adalah Observable.

Gerakan konsumen dan transformasi aliran


Operasi transformasi aliran dapat dilakukan baik dalam perjalanan ke konsumen dan sendiri. Dalam kedua kasus, operasi pemrosesan elemen aliran secara ketat berurutan, yaitu operasi berikutnya diluncurkan secara ketat hanya setelah yang sebelumnya selesai dan melewati hasilnya.
Tidak seperti Stream, yang dalam beberapa bahasa pemrograman merupakan konstruksi bahasa dengan sintaks dan semantik mereka sendiri, ekstensi reaktif seperti RxJS dalam JavaScript dipaksa untuk menggunakan sintaks dan semantik dasar bahasa yang dapat dikembangkan. Oleh karena itu, RxJ mengimplementasikan fungsi pipe (), di dalamnya Anda dapat menempatkan panggilan ke fungsi - pengendali aliran itu sendiri dan elemen individualnya.
Penting untuk dicatat bahwa hanya fungsi-fungsi khusus, dapat dipipihkan, yang dapat menjadi penangan aliran.

"Aliran tiga fase"


Jika kita melanjutkan analogi dengan listrik, maka aliran yang kita pertimbangkan dapat disebut tiga fase. Bersamaan dengan "kawat normal" yang mengirimkan informasi dasar, ada juga "kawat kesalahan" dan "kawat terminasi aliran". Operasi transformasi memungkinkan tidak hanya mengubah objek, tetapi juga mengarahkannya ke "kawat" lain. Teknik ini digunakan, misalnya, ketika memproses dugaan kesalahan dalam bekerja dengan server menggunakan protokol HTTP. Misalnya, jika satu server tidak merespons, Anda dapat mencoba meminta yang lain tanpa memberi tahu pengguna tentang kegagalan untuk meminta server pertama.
Ini adalah elemen lain yang sangat penting dari Model Aliran Mental Anda. Jika dalam paradigma pemrograman tradisional kesalahan dikembalikan dari fungsi pemrosesan sebagai kode kesalahan atau harus dicegat sebagai gangguan (pengecualian), maka dalam arus kesalahan "mengalir" tidak tergantung pada saluran utama.
Di sana itu bisa diproses. Misalnya, jika pengguna memasukkan kata sandi yang salah, mereka mungkin diberi kesempatan tambahan untuk mencoba memasukkannya satu kali atau lebih.

Memisahkan dan menggabungkan aliran


Pemisahan arus dilakukan dalam dua tahap. Pada tahap pertama, utas kosong dimulai. Kemudian, pada tahap kedua (tahap pemrosesan aliran), di salah satu fungsi pemrosesan, elemen akan dianalisis dan dialihkan ke aliran yang diinginkan. Secara teknis, ada banyak opsi untuk melakukan hal ini. Misalnya, menghapusnya dari utas saat ini atau mengkloningnya sebelum memulai dengan utas baru.
Anda dapat menggabungkan beberapa aliran menjadi satu dalam banyak cara yang mengejutkan.
Cara paling sederhana yang muncul dalam pikiran adalah menggabungkan mereka dalam urutan penerimaan, atau pertama-tama semua dari aliran pertama dan kemudian semua dari yang kedua.
Metode yang ditunjukkan di bawah ini dalam gambar memungkinkan satu dari dua aliran untuk membentuk satu berisi pasangan objek yang diurutkan dari aliran pertama dan kedua. Dalam hal ini, pasangan baru terbentuk jika elemen baru muncul di salah satu aliran. A berisi sepasang elemen terakhir dari setiap aliran. Ini mengarah pada fakta bahwa elemen yang sama dapat dimasukkan dalam beberapa pasangan.
Notasi grafis yang digunakan dalam contoh ini disebut diagram Marmer dan sangat efektif dalam menjelaskan semantik dari aliran yang memisahkan dan menggabungkan.
Jika topik ini menarik minat Anda, saya sarankan Anda untuk mempelajari operasi dan diagram Marmernya pada sumber daya [8].


Menggunakan stream


Untuk menggunakan elemen aliran, pengguna atau klien harus berlangganan terlebih dahulu. Sebagai aturan, pada akhir pemrosesan, ia harus berhenti berlangganan, karena pemulung tidak selalu secara otomatis menonaktifkan langganan ketika mereka mencoba memanfaatkan pelanggan.
Banyak klien dapat berlangganan ke satu utas. Dalam RxJs, fungsi berlangganan disebut berlangganan (). Di dalamnya, dalam kebanyakan kasus, disarankan untuk menempatkan panggilan pemrosesan elemen "normal" stream, penangan kesalahan dan (relatif jarang) penangan pemutusan aliran.
Setiap pelanggan pada aliran menerima salinan elemen atau klon dari elemen asli. Agar tidak menimbulkan masalah, aliran diimplementasikan sedemikian rupa sehingga elemen yang diterima untuk diproses menjadi tidak berubah. Dalam beberapa situasi, batasan ini masih bisa dielakkan, tetapi lebih baik tidak dilakukan.

Pesona aliran sungai yang berbahaya


Streaming adalah objek yang sangat rumit, agak mirip dengan integral dalam matematika. Adalah satu hal untuk mengetahui bahwa mereka ada dan bahkan secara kasar membayangkan apa itu, dan benar-benar lain untuk dapat menggunakannya.
Memahami logika internal fungsi mereka, perlu untuk menerapkannya dengan baik dalam praktik, membutuhkan upaya intelektual yang cukup besar.
Streaming secara intrinsik berkaitan erat dengan pemrograman fungsional. Untuk penggunaan aliran yang kompeten, penting untuk memahami bagaimana membangun dan menerapkan fungsi urutan kedua - fungsi yang fungsi lainnya berfungsi sebagai argumen.
Maka keindahan dan keanggunan aliran akan sepenuhnya terungkap kepada Anda.
Streaming menular. Setelah memahami kecantikan mereka, saya ingin menggunakannya dalam semua tugas, yang tentu saja tidak perlu.
Dalam tugas apa yang disarankan untuk menggunakan aliran, dan di mana metode tradisional harus digunakan, semua orang memutuskan untuk dirinya sendiri.

Meringkaskan


Dalam artikel ini saya mencoba untuk memberi tahu Anda tentang Model Mental Pemrograman Reaktif (MM RP) dan bahkan sebagian meletakkannya dalam Kesadaran Anda. Mari kita ulangi poin utama lagi.

  1. MM RP khusus, tidak mirip dengan Model Mental Pemrograman tradisional.
  2. Ketika memulai Pemrograman Reaktif, kita harus ingat bahwa beberapa mapan di bidang MM lainnya seperti kursor, rantai panggilan atau loop tidak berfungsi, atau mereka tidak bekerja seperti itu.
  3. Model Mental utama RP adalah aliran "tiga saluran" dengan saluran untuk elemen "normal", kesalahan, dan informasi tentang akhir aliran.
  4. Streaming dapat terbatas dan tidak terbatas.
  5. «», «» «» . «» «».
  6. . (, ). .
  7. , .
  8. , .
  9. . .
  10. , «».


Jika Anda tertarik dengan topik ini, Anda bisa "bermain" dengan stream menggunakan simulator yang tersedia di situs [8].
Jika Anda ingin lebih memahami konsep-konsep RP, saya sarankan Anda bekerja melalui buku [7], dan tentu saja, berkenalan dengan The Reactive Manifesto [11].
Anda akan mencapai level berikutnya dalam pembentukan MM RP Anda sendiri dengan mengerjakan buku [9] dan [10] pada desain dan pemodelan sistem reaktif.

Sastra dan referensi


  1. Pemrograman adalah perwujudan gagasan. (Artikel tentang Habr. Habr.com/ru/post/425321 )
  2. Sirotin V. RPSE: Reifikasi sebagai Paradigma Rekayasa Perangkat Lunak. arxiv.org/abs/1810.01904
  3. Pemrograman berbasis acara. en.m.wikipedia.org/wiki/Event-driven_programming
  4. Dataflow-programming. en.m.wikipedia.org/wiki/Dataflow_programming
  5. Stream-processing. en.m.wikipedia.org/wiki/Stream_processing
  6. Rx-Extensions: reactivex.io/languages.html
  7. RxJS in Action. – 4. August 2017. Paul P. Daniels (Autor), Luis Atencio. Manning Publications. ISBN-13: 978-1617293412
  8. RxJS online Documentstion. xgrommx.imtqy.com/rx-book/index.html
  9. Reactive Design Patterns. 2017. Roland Kuhn Dr., Brian Hanafee, Jamie Allen. Manning Publications. ISBN-13: 978-1617291807
  10. Functional and Reactive Domain Modeling. 2016. Debasish Ghosh.Manning Publications. ISBN-13: 978-1617292248
  11. The Reactive Manifesto www.reactivemanifesto.org


: geralt

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles