Engineering Notes

HTTP/3 yoki xayr TCP.
Request multiplexing juda ajoyib yechim edi, faqat bitta jiddiy muammosi bor ekan. TCP stateful protocol va uni agar dataning bir qismi yetib kelmasa, ma'lum vaqtdan keyin qayta uzatiladi va bu oraliqda yetib kelgan ma'lumot ham bloklanib turadi. Bu narsa OSIda 4-qavatda sodir bo'ladi, HTTP esa 7-qavatda. Demak, biz yuborgan 10 ta HTTP request TCP uchun shunchaki bir butun data, u request nimaligini ham bilmaydi. Natijada o'sha 10 ta requestdan birortasi qisman yetib kelmasa ham TCP hamma requestlarni bloklaydi. Bu HOL blocking deyiladi.
Bu muammoni hal qilish uchun h3 (RFC 9114) TCPdan voz kechib, UDP ustiga qurilgan QUIC protocolidan foydalanadi. UDPning o'zida retransmission yo'q. QUIC bu narsani o'zi ishlab chiqdi va buning TCPdagi retransmissiondan farqli jihati, QUIC bitta connection ichidagi HTTP requestlarni bir-biridan ajrata oladi. Sababi, QUICning o'zida multiplexing xususiyati bor va u retransmission bilan bitta layerda joylashgan. Natijada request to'liq yetib kelmasa butun boshli connection emas, faqat o'sha request bloklanadi.

Xo'sh, shu bilan muammolar tugadimi? Albatta yo'q. Muammolarni yechishda davom etamiz...
Bu maqolani yozishdan maqsad HTTPning evolutsiyasi haqida qisqacha ma'lumot berish va sizni bu borada yana izlanishga undash. Xato va kamchiliklarni aytib, feedback qoldirsangiz, xursand bo'laman.

Foydalanilgan manbaalar:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
https://en.m.wikipedia.org/wiki/Hypertext_Transfer_Protocol
https://datatracker.ietf.org

P.S. Tanishlarga share qilinoradi 🙂

@boboshersnotes

1990-yillar, internetni faqat ma'lum tashkilotlar orasidagina emas, butun dunyo bo'ylab ishlatish g'oyasi bilan chiqqan WWW endi tug'ilgan vaqtlar. IP, TCP, OSI kabi internetning "building block"lari allaqachon ishlab chiqilgan, lekin WWW uchun standartlar kerak edi. Ma'lumotni foydalanuvchiga yetkazish tili sifatida HTML ishlab chiqildi (va bu tildagi ma'lumotni render qilib, UIda ko'rsatish uchun browser ishlab chiqildi).
Networking uchun TCP va UDP kabi transport layer protocollar ishlab chiqilgan bo'lsa ham, tez, yengil, ishonchli va asosiysi, application layerda ishlaydigan protocol ishlab chiqishga ehtiyoj tug'ildi.

Shunday qilib HTTP ishlab chiqildi. Dastlabki versiya o'ta sodda va imkoniyatlari kam edi. Path orqali murojaat qilib, serverda turgan faylni yuklab olish mumkin edi xolos (faqatgina GET methodi bor edi). Keyinchalik bu versiyani boshqalardan farqlash uchun HTTP/0.9 deb nomlandi.

Keyingi versiyalarga to'xtishdan oldin HTTPning o'zi haqida biroz:
HTTP application layerda ishlaydigan, TCP protocoli ustiga qurilgan (h3 gacha), client-server modelini support qiladigan stateless protocol.
Nega stateless? Sababi protocol yengil va tez bo'lishi kerak edi. Stateful bo'lish esa protocolni og'irlashtirish va sekinlashtirishga olib keladi. Qiziq, unda nega stateful network protocol (TCP)ning ustiga qurildi? Sababi, protocol ishonchli bo'lishi kerak edi. TCP state orqali data to'liq yetkazilishini ta'minlaydi. Davom etamiz.

Tim Berners-Lee va uning jamoasining ko'p mehnatlaridan so'ng va nihoyat 1996-yil HTTP/1.0 rasman standart bo'ldi va RFC 1945 sifatida kiritildi.
Xo'sh bu versiyaga asosan nimalar kiritildi?
1. Status kodlari. Bu orqali browser request success bo'lgan yoki bo'lmaganini aniqlash imkoni tug'ildi.
2. POST va HEAD methodlari.
3. Request headerlar. Bu juda ko'plab yangi imkoniyatlar eshigini ochdi, masalan, hypertextdan boshqa content typelar bilan ishlash).
Jamoa esa tajriba qilishda davom etdi.

1 yildan keyinoq HTTP/1.1 ishlab chiqildi va RFC 2068 sifatida taqdim etildi. O'zgarishlar:
1. Bitta TCP connectionni keyingi request uchun qayta ishlatish imkoniyati. Sababi, TCP connection ochish ancha "qimmat"ha tushadi va bitta connectionni uzoqroq ishlatish kerak.
2. Yangi request methodlari.
3. Content haqida ko'proq metadata.
4. Katta hajmli responseni bo'laklab yuborish imkoniyati.
Keyingi yillar davomida WWW ancha takomillashdi, protocolga qo'yilgan talablar oshdi va natijada HTTPga yana ko'plab o'zgarishlar qo'shib borildi. Bir muammo borgan sari jiddiylashib bordi: bir nechta request yuborish uchun avvalgi requestga response kelishini kutib, undan keyingina keyingi requestni yuborish mumkin edi. Natijada client resurslarni olish uchun juda ko'p vaqt sarflashga majbur edi. Buni hal qilish uchun bir vaqtning o'zida 6 tagacha parallel connection ochib, request yuborish imkoniyati qo'shildi. Bu HTTP/1.1 ning 1.0 ga qaraganda eng ustun jihatlaridan biri bo'ldi. TLSni support qilish orqali protocol HTTPS deb atala boshlandi va shunga o'xshash bir nechta juda muhim yangilanishlar bo'ldi. 1.1 juda omadli chiqdi: tez, yengil va muhimi, moslashuvchan. Lekin shu bilan birga ba'zi jiddiy muammolari ham bor edi...

2015-yil, 1.1 versiya yaratilganidan 18 yil o'tib avvalgisidan ancha farq qiladigan zamonaviy protocol – HTTP/2 ishlab chiqildi (RFC 7540).
1.1 ko'plab requestlarni 6 ta parallel connection orqali hal qilgandi, lekin bu endi ancha samarasiz bo'lib qoldi. H2 da bu juda chiroyli usulda yechildi: bitta TCP connectionda bir vaqtda ko'plab request yuborish imkoniyati (bu narsa multiplexing deyiladi) bor va muhimi avvalgi requestga response kelishini kutib o'tirish shart emas! Shunchaki o'nlab request yuborasiz va server birin-ketin javob beraveradi. Responselar aralashib ketmasligi uchun har bir requestga ma'lum ID beriladi va server shu ID bilan response qaytaradi. Ha, bu "game changer" feature bo'ldi. Bundan tashqari juda ko'plab o'zgarishlar bor, qolganini o'zingiz topib o'qiysiz.

@boboshersnotes

Testing is not over-engineering.
AUF☝️

P.S. Change my mind.

"Hozircha ishlaydigan" yechim qilmang.
Sizdan keyin ishlaydiganlarga rahmingiz kelsin...

"Sifatli softwarega kuchli toollar orqali emas, kuchli dasturchilar orqali erishiladi." – degandi David West.
Bu degani tool qanchalik zo'r bo'lmasin, u to'g'ri ishlatilmasa "bir tiyinga qimmat".

Masalan, GraphQL hozir ancha mashhur bo'lib ketdi. Xo'sh savol, uning RESTdan eng ustun tomoni nima? Flexibility!
Facebookdagilar aynan shuning uchun GraphQLni yaratgan. Clientda RESTdagiga o'xshab o'ziga kerakli 2-3 ta fieldni olish uchun butun boshli ulkan obyektni emas, faqat o'zi so'ragan, o'zi uchun yetarli minimal datani olish imkoniyati bor. Bu aslidan minglab marta sodda ko'rinishdagi tushuntirish.

Xo'sh, buni texnologiyani noto'g'ri ishlatayotganlar ham bormi?
Ochig'ini aytganda, faqat sanoqli kompaniyalargina to'g'ri ishlata olayapti. Men siz yaqinda ishlab chiqqan CRM yoki lokal bank tizimi haqida gapirmayapman. Hattoki Twitterga o'xshash kuchli mutaxassislarga ega texnogigantlar ham implementatsiyaga kelganda oqsoqlanayapti. Ishonmaysizmi? Twitterning web versiyasini inspect qilib, network panelni kuzating, o'zingiz ko'rasiz.

Qisqasi, Python PHPdan zo'r deyishdan oldin post boshidagi gapni o'qing.

P.S. "Sen kim bo'libsan Twitterning ogorodiga tosh otadigan?" deydiganlarga javob – mashinaga baho berish uchun oldin o'zingiz mashina qurishingiz shart emas (ayniqsa bizda).

Ko'pchilik DBMSlar client-server (server bu yerda database) communication uchun alohida protocollar ishlab chiqqan.
Ya'ni networking uchun ularning alohida protocoli bor.
E'tiborli jihati, ko'p DBMSlarda bu communication davomida va ayniqsa connection ochish vaqtida juda ko'p metadata almashiladi (o'zim PostgreSQL va MongoDBda kuzatdim).

Bu databaselar bilan ishlayotganda connection ochish ancha "qimmat"ga tushadi degani. Bitta connectionni uzoqroq ishlating (albatta, butunligiga ishonch hosil qilib) yoki connection pool ishlating.

P.S. Har bitta query uchun alohida connection ochadigan tanishlarga yuboramiz ))
P.S.2. PHPchilarga yuboramiz ))

Ba'zan klassik muammolar oddiy, nozik yechim talab qiladi.

Masalan, MQ va Pub/Sub tizimlari duch keladigan klassik muammolardan biri latency va data persistency orasidagi "oldin nuqta"ni topish. Messagelarni memoryga yozish va o'qish tez, lekin persistencyni ta'minlash qiyin masala. Storagaga yozish ancha mustahkam yechim, lekin shu bilan birga ancha sekin.

Ko'pchilik MQlar (masalan, RabbitMQ) yuqoridagi ikkita yechimni ma'lum darajada birlashtirib, o'zlari uchun to'g'ri keladigan yechim ishlab chiqqan. Menga esa Kafka qo'llagan usul yoqadi. Xo'sh bu qanday yechim?
Shoshmang, yechimdan oldin muammoni yaxshilab tushunib olaylik.

Nega storagaga yozish/o'qish sekin?
Birinchidan, bu I/O operation, ikkinchidan storageda random access yo'q. Hajmi juda kichkina bo'lgan 100 ta message har xil joydagi 100 ta blokka yozilgan bo'lsa, ularni olish uchun 100 ta blokni to'liq yuklab olish, ya'ni 100 ta I/O kerak bo'ladi. Ya'ni bu usulning effektivligi past va sekin. Lekin agar o'sha 100 ta messageni ketma-ket turgan 2-3 ta bloklarga yozsakchi? Unda 100 ta message uchun 2/3 ta blokni o'qish yetarli bo'ladi. Va undan ham yaxshi tomoni, ketma-ket turgan bloklarni o'qish storagening narigi burchagida turgan blokni borib o'qishdan ko'ra tezroq bo'ladi. Kafka xuddi shunday qiladi. Ya'ni messagelarni storageda yonma-yon yozib, shu ketma-ketlikda o'qiydi.

Ko'rayapsizmi, yechimlar har doim ham murakkab bo'lishi shart emas. Shunchaki asl muammoni chuqurroq o'rganish va ozgina kreativ fikrlash chiroyli yechimlarga olib keladi (afsuski, har doim ham emas).

Bugun bo'sh vaqtim ko'proq bo'lgani sabab o'zimni anchadan beri qiziqtirayotgan savollarga javob izlash va yana yangi kitob o'qishni boshlashga imkon bo'ldi.

Anchadan beri LinkedIn ishlatadigan Galene search engine (well, architecture) qanday ishlashiga qiziqayotgandim, bugun shu haqida ozroq ma'lumot topib (o'zi unchalik batafsil ma'lumot topa olmadim), o'qib ko'rdim. Xuddi kutganimdek, ancha murakkab tizim ekan.

Ko'pchilik backend engineerlar uchun database "shunchaki" ma'lumot saqlaydigan servis va bu qisman to'g'ri. Lekin tizimdan foydalanuvchilar minglab emas millionlab bo'lganida, ma'lumot hajmi gigabaytlar emas, petabaytlar bo'lganida hammasi o'zgaradi. Klassik qarashlar ortidan kelgan yechimlar ish bermay qoladi (xuddi kvant olamida klassik mexanika qoidalari ishlamaganidek). Yangicha yechim topish uchun muammoga boshqa tomonlardan qarab ko'rish kerak bo'ladi.

Nega LinkedIn faqatgina search (klassik CRUDning 1 ta elementi) qilishning o'zi uchun alohida engine ishlab chiqdi? Shunchaki bitta PostgreSQL instance yurgizib qo'yib, LIKE orqali search qilsa bo'lmasmidi?
Yo'q do'stim, hammasi bunchalik oddiy emas. Buning uchun biznes talablarini qondiradigan (har xil modellar ustida bitta query, natijalarni hudud, qiziqishlar, tanishlar kabi bir qancha metadata bo'yicha rank qilish, logik va grammatik alternativlar bo'yicha izlash, ...) va texnik jihatdan batafsil o'ylangan (latency, CPU va RAM limitlarini hisobga olish, ma'lumotlarni saqlash usulining storage va OS leveldagi muammolarini hisobga olish, optimizatsiya qilish, failurelar va attacklarga qarshi mexanizmlar bilan jihozlangan) tizim ishlab chiqish kerak bo'ladi. Va bu overengineering emas. Mana shu yerda esa "Database shunchaki ma'lumot saqlaydigan servis" degan gap o'zini oqlamaydi.

Microservices are evil.
Yes, now I totally agree with JR ))

P.S. And I'm realizing this in a painful way.

Hali ko'rmaganlar uchun:
https://youtu.be/wlRbDg8-QH0

P.S. Xato va kamchiliklarini commentda yozsangiz xursand bo'lardim.
Bu keyingi talklar yaxshiroq bo'lishiga xizmat qiladi.

Celeryning arxitekturasida, ayniqsa networking qismida yetarlicha muammolar borligi haqida avvalroq yozgandim.

2019-yil Doordash asinxron tasklar uchun RabbitMQ + Celery stackdan Kafka + custom workerlarga o'tishiga asosiy sabablardan biri ham aynan Celeryning networking muammolari bilan bog'liq bo'lgan ekan.
Doordash Engineering blogida bu jarayon qanday o'tgani haqida batafsil maqola bor ekan. Asosiy va ikkinchi darajali muammolarni analiz qilishdan boshlab potensial yechimlarni ko'rib chiqish, yangi arxitekturaga qanday muammosiz o'tish/moslashish va yangi arxitekturadagi muammolar qanday tuzatilganigacha yozilgan (batafsil bo'lmasa ham, yetarlicha).
Erinmasdan oxirigacha o'qib chiqishni tavsiya qilaman:
https://doordash.engineering/2020/09/03/eliminating-task-processing-outages-with-kafka/

Algoritmlar bilan ishlashni endi boshlaganlarida tug'iladigan klassik savol:
Sort qilinmagan arrayda biror elementni izlash O(n) vaqt talab qiladi.
Sort qilingan arrayda esa qidiruv O(log n), lekin sort qilishning o'zi O(n * log n) vaqt oladi. Demak, arrayni sort qilib, elementni izlash sort qilinmagan arraydagi qidiruvdan ko'ra ko'p vaqt oladi. Unda sort qilishning nima keragi bor?

Javob: Sort qilinmagan arrayda har bir search uchun O(n) sarflanadi. Sort qilingan arrayda esa sort qilish uchun esa O(n * log n), keyingi har bir search uchun O(log n) vaqt sarflanadi. Bir martalik operatsiya uchun sort qilmasdan qidirish tezroq bo'lsa-da, umumiy m ta (m >> n) qidiruv uchun sort qilmasdan qidirish O(m * n), sort qilib, keyin qidirish esa O(m * log n) vaqt talab qiladi.
Xulosa qilganda, kelajakdagi qidiruvlarni ham hisobga olganda, arrayni tartiblash foydali.

P.S. Bu savolni yaqinda bir guruhda ko'rgandim, bugun bir kishi shaxsiyda shu savolni so'rabdi. Kimgadir foydali bo'lsa, xursand bo'laman.

PostgreSQLda index create qilayotganda fillfactor nomli parameter bor. Qisqasi, b-tree page(node)ning qancha qismi to'lganidan keyin bu index pageni to'lgan deb hisoblanib, keyingi pagega yozishni boshlashni bildiradi. Nega 100% to'ldirib, keyin keyingi pagega o'ta olmaymiz? Sababi pageda valuelar tartiblangan bo'ladi, agar tartib bo'yicha shu to'lgan pagega to'g'ri keladigan yangi qiymat kiritilsa, uni shu yerga sig'dirish uchun pageni split qilib, qayta organize qilishga to'g'ri keladi. Bu xuddi arrayning o'rtasiga element qo'shish uchun undan keyingi qismini orqaroqqa surishga o'xshaydi, lekin storege levelda bu yanayam "painful" bo'ladi. Buning oldini ma'lum darajada olish uchun pagening bir qismini oldindan bo'sh qoldirib qo'yish mumkin. Shu pageda turishi kerak bo'lgan yangi qiymat kelganida qolgan valuelarni bezovta qilmasdan, shu yerning o'ziga sig'dirish mumkin bo'ladi.

Index fillfactor index pagening necha foizi to'lganidan keyin yangi pagega o'tishni ko'rsatadi. Default holatda 90%, ya'ni 10% qismi bo'sh turadi. PostgreSQL dokumentatsiyasi bu qiymatni 50-90 foiz oralig'ida ushlashni tavsiya qiladi.
Kamroq fillfactor write operationlar kutilmaganda sekinlashib qolishini kamaytiradi, lekin searchni biroz sekinlashtiradi (fillfactor past bo'lsa, index pagelar soni ko'payadi, ko'proq page ko'proq vaqt degani) va ko'proq joy oladi.

Qachon fillfactorni yuqori qilish tavsiya qilinadi:
1. Tableda write operations juda kam bo'lsa yoki umuman bo'lmasa. Deyarli yoki to'liq static table 100% index fillfactordan kamroq zarar ko'radi.
2. Read performance write performancedan ko'ra muhimroq bo'lsa.
3. Qiymatlar aynan tartib bilan kiritilsa va updatelar juda kam bo'lsa.

Qachon fillfactorni pastroq qilib belgilash tavsiya qilinadi:
1. Write operationlar juda ko'p va tartibsiz bo'lsa.
2. Write performance read performancedan ko'ra muhimroq bo'lsa.
3. UUID yoki GUID bilan ishlaganda.

#paradigms

Biror dasturiy ta'minotni tuzish uchun xozirgi kunda ko'p holatda juda yuqoridan qaraymiz. Frameworklar tayyor solutionlar pattenlar. Albatta bular muhim ammo juda ko'p xamkasblarda asosiy muammo paradigmalar. Ko'plab dasturchilar uslub, yondoshuvni dasturlash tillaridan olishadi (Shaxsan o'zim ham shu kungacha). Lekin ushbu xolatda bizda bir tomonlama fikrlash juda o'sib ketishi mumkin. Bu esa albatta birkun zararga ishlashi mumkin.

Nega ? Bazi tillarda faqat bir paradigmani tadbiq qilingan. Bu esa umumiy dasturlashni shu doirada ko'rishga o'rgatadi Masalan C. Bazilarida esa multi paradigm lekin juda tartibsiz va sifatiz code yozish extimoli yuqori. Masalan JS. Bazi tillarda til implement qilgan paradimgdan boshqasini tadbiq qila olmaysiz bu bir tomondan juda zo'r boshqa tomondan unchalik emas. Agar shunday bo'lsa JS kabi bo'lish extimoli yurqori.

Yuqorida aytganimday biror muammoga nisbatan berilgan yechim turli yo'llar orqali qilingan bo'lishi mumkin.

Anchadan buyon faqat JS/TS stackda ishlab shu paradigmlar masalasida ko'p chalkashaman. Endi yaxshi expirement boshladim. Paradigmlarni boshqa tillarda o'rganishni boshladim bu narsa ushbu falsafalarni yaxshiroq tushunish va tadbiq qilishga yaxshigina yordam beryabti. Masalan ruby va Java Rubydagi OOP manga ancha yoqdi Javaga qaraganda. Syntax yondoshuv va implementation ancha sugar. Paralell programming uchun esa Go birmuncha yoqdi. Functional programmingni Elixirda sinab ko'rvoman. Bu tajribalar manimcha yillar davomida bo'ladi chunki aniq biror muammoga ushbu bilimlarni tadbiq qilib ko'rish kerak. Lekin bir narsani tushundimki Universal Dasturlash tilining yo'qligiga asosiy sabablardan biri bu paradigmlar ko'pligi. Bu tajribani boshlaganimdan keyin ancha yegilib qolgan savollarga javob topishni boshladim. Lekin xozircha JS/TS dan boshqasida erkin emasman. Manimcha dasturlashni o'rganishda eski classic progamming yoki old school unchalik mos emas xozirgi kunda.

Misol uchun JS bilan OOP o'zini o'rganish birmuncha qiyin yoki design patternlani. Yoki C++ bilan FP ni o'rgana olishiz qiyin. Undan ko'ra aynan OOP yoki FP yaxshiroq tadbiq qilingan tilda o'rgangan yaxshiroq deb o'ylayman. System engineering uchun C ancha qiziq edi manga. Ammo fikrim o'zgardi Rust.

Sizda ham shunday bo'shliqlar bo'lsa qanday to'ldirasiz yoki hali bo'lmagan bo'lsangiz sabringiz yetsa yuqorida yozganimday uslubni tavsiya qilaman.

PS: Ushbu postdan maqsad tillarni yaxshi yomon deb solishtirish emas. Dasturlashni yaxshioq o'rganish va chuquroq tushunish uchun bir uslubni yoritishdan iborat.

PS++: Postda qaysidur tilni yaxshi bilish yoki bilmaslikga davo qilinmagan !!!

Emotional damage 😢

Shaxsiy fikrim:

Ha, ko'pchilik frameworklar antipatternlar asosiga qurilgan va bu ma'lum darajada asosli.
Agar frameworklar to'liq biz bilgan toza konseptlar asosida yozilganida ular orqali minimal "ishlaydigan" kod yozish hozirgidan ko'ra ancha qiyin bo'lgan bo'lardi.

$20 ga bozordan sifati meni qoniqtiradigan krossovka sotib olsam, Nike meni ularning san'at asari darajasida ishlab chiqilgan $200 turadigan krossovkasini sotib olmaganim uchun ayblay olmaydi. Sababi, menda o'sha mahsulotga ehtiyoj va yetarli mablag' yo'q. O'zim olgan mahsulot sifat va narx jihatidan meni qoniqtiradi.

Xuddi shunday, ko'pchilik kichik va o'rta kompaniyalar va ularning tepasida o'tirgan biznesmenlar uchun siz va men qurishni xohlaydigan ideal (yoki shunga yaqin) dastur kerak emas. Buning uchun ehtiyoj va yetarlicha resurs yo'q ularda.
Siz va men ular aytgan resurslar evaziga software ishlab chiqishga rozi bo'lmasak ham, buni qiladiganlar albatta topiladi va bu tabiiy. Keyin sifat ham shunga yarasha bo'ladi.

Ko'pchilik frameworklar esa o'sha "qoniqarli sifatli" software ishlab chiqish uchun arzon yarimtayyor mahsulot. Agar o'sha frameworklardan foydalanib, yuqori sifatli dastur ishlab chiqmoqchi bo'lsangiz, frameworkni anchagina customize qilishingiz kerak va FAANGda ham shunday qilishadi.

Frameworklar ko'p holatlarda biror ishni osonlashtirish uchun ishlab chiqilgan yoki ishlab chiqiladi. Lekin juda ko'p frameworklar antipatterlar asosiga qurilgan. To'g'ri u nimadurni yaxshilaydi nimaduni osonlashtiradi samaradorlikni oshiradi deyiladi. Lekin ko'p holatlada qo'pol ravishta patternlar va prinsplarga zid ishlar qilinadi. Notogri ideologyni imrove qiladi. Masalan ko'p frameworklada controller tushunchasi mavjud. Bu narsa handler vazifasini bajaradi. OOP tomonlama qarasa bu holatda class qandaydur protseduralar yegindisi bo'lib qoladi )) Yoki boshqacharoq misol:

DTO tushunchasi. Getter va setterlar yegindisi. Bu component yoki layer ko'p holatlarda shunchaki protseduralar yegindisiga aylanadi. Object o'z hususiyatlarini yoqotadi.

Inkapsulyatsiya

Inkapsulyatsiyaga misol:
- Shashlik yemoqchisiz, shashlikchini oldiga bordingiz
- Mana 2 kg go'sht,1kg qiyma,1kg jaz shashlik bo'lsin
- Go'shtni berasiz, u sizga tayyor shashlik qilib beradi

Nimasi inkapsulyatsiya?
- Shashlikchi - Class
- Unga go'sht berasiz - constructor
- Shashlikka qo'shiladigan ziravorlar - property
- Shashlik qilish uchun myasarovkadan chiqaradi, marinovka qilish, muzlatadi - bular methodlar
- Shashlikga qo'shadigan ziravori bor, uni faqat shashlikchi biladi - private property
- Shashlik sixdan oqib tushmaslik uchun xxx ishni qiladi, bu ham uni siri - private method
- Shashlikchi shu sirlarini faqat farzandlariga o'rgatgan, ular ham bu shashlik qilish usulidan foydalanishadi - protected method

Siz shashlikchini qanday tayyorlaganiyu nimalar qo'shganini, hammasini bilolmaysiz, lekin shashlik tayyor.
U shu private va protected sirlarini tashqariga chiqarishni xohlamaydi - manashu inkapsulyatsiya, ya'ni sirlarini himoyalaydi.

Xato misol bo'lsa iltimos to'g'rilang.

Bruce akadan PostgreSQL indexlar haqida ajoyib talk. Oxirigacha ko'rishni tavsiya qilaman.

https://youtu.be/QQ1eyBcphEs