SOLID tamoyillari

SOLID - bu dasturiy ta'minotni ishlab chiqish uchun 5 ta muhim tamoyil hisoblanadi.

S — Single Responsibility

Misol uchun bizda User classi mavjud. Agarda User classi ko'p vazifalarga ega bo'lsa, u xatolar ehtimolini oshiradi. Sababi User classining biror bir qismi o'zgarsa, boshqa qismlarining o'zgarishiga olib kelishi mumkin. Single Responsibility tamoyilining asosiy maqsadi alohida qismlarga ajratib ishlashga qaratilgan. Misol uchun User classining ikkinchi darajali metodlari alohida yangi classga o‘tkaziladi.

O — Open Closed

Bu tamoyilda class kengaytirishlarga ochiq, o'zgarishlarga esa yopiq bo'lish kerak. Misol uchun bizda qandaydir class mavjud bo'lsa va u classning biror bir metodiga yangi imkoniyat qo'shilsa, o'sha classning metodiga shartlar qo'yib yana uni test qilish uchun hamma qismini test qilishga to'g'ri keladi. Open Closed tamoyilining asosiy maqsadi shu holatni oldini olish. Yani class biror metod bo'lsa va yangi imkoniyat qo'shilganda yangi class yaratilib u asosiy classning metodidan foydalaniladi. Shunda biz faqatgina oxirgi qo'shgan imkoniyatimizni test qilishga erishamiz.

L — Liskov Substitution

Bu tamoyilga binoan ota class bajara oladigan amallarni bola class ham bajara olish kerak. Agar bola class ota class bajara oladigan amallarni bajara olmasa xatolik yuzaga kelishi mumkin. Tasavvur qiling, Vehicle degan ota class bo'lsa, Car va Bus class'lari bola class hisoblanadi. Endi Liskov Substitution tamoyiliga binoan Car va Bus ham Vehicle bajara olgan amallarni bajara olishi kerak yoki bir xil turdagi natijani berishi kerak.

I — Interface Segregation

Foydalanuvchi o'ziga kerak bo'lmagan interface'dan foydalanishga majbur bo'lmasligi kerak. Bu tamoyilga binoan umumiy interface'lardan ko'ra bir qancha kichik interface'lar afzalroq. Tasavvur qiling, dasturdan foydalanuvchilarning ba'zilari uchun qandaydir metod kerak bo'lib qoldi. Ammo biz asosiy interface'ni o'zgartirsak qolgan foydalanuvchilar uchun bu metod mavjud bo'lib qoladi, zero ular foydalanishni hohlamasalar ham. Bunday holatda Interface Segregation'ga amal qilgan holda asosiy interface'dan meros olib yangi metodni qo'shib kerak bo'lgan foydalanuvchilarga taqdim etamiz. Shunda har bir foydalanuvchi o'ziga kerak bo'lgan interface'dan foydalanadi. Va xatoliklar chiqishi ehtimoli kamayadi.

D — Dependency Inversion

High-level level'dagi modullar low-level modullarga qaram bo'lib qolishi kerak emas. Misol uchun Notification class'i mavjud bo'lsa send message va send email metodlari notification'ga emas balki biror bir abstraction'ga tegishli bo'lishi kerak. Yani send message hamda send send email metodlari Messaging class'iga tegishli bo'lishi kerak va Messanging class'i esa Notification class'iga bog'langan bo'lishi kerak.

Maqola foydali bo'lgan bo'lsa do'stlaringizga ulashing!

@usmon_masudjonov

Ma'lumotlar bazasi (database) nima va u nima uchun kerak?

Deyarli barcha turdagi dasturlar ma'lumotlar bilan ishlaydi. Ma'lumotlarni saqlaydi, o'zgartiradi, o'chiradi va hokazo.

Database (DB) bu shu ishlarni tartibli va samarali usulda qiladigan tizim/dastur.

"Lekin, ma'lumotlarni o'zgaruvchilarda, hashmaplarda, arraylarda ham saqlash mumkinku" deyishingiz mumkin. To'ppa to'g'ri. Ularda ham saqlash mumkin.

Muammo shundaki, ular ma'lumotlarni RAMda saqlaydi va dasturingiz/programmangiz to'xtatilishiga u ma'lumotlar yo'qoladi.

"Agar to'xtatmasakchi? Buni ilojisi borku". To'g'ri. AWS, GCPlarning serverlariga qo'yilsa, shunday qilsa bo'ladi. Ularda svet o'chmaydi. Har qalay serverlari bizda Andijonning Shaxrihon qishlog'ida joylashmagan. Lekin, Amerikalarda ham to'fonlar bo'lib turadi ;) To'xtamagan taqdirda ham RAM odatda chegaralangan bo'ladi.

Demak bizga boshqa bir ma'lumotlarni saqlash usuli kerak.

"Ha, text fayllarda saqlasak bo'ladi" deysizmi? To'ppa to'gri! Kundalikni olib keling.

Muammo shundaki text fayllar yetarlicha murakkab dasturlar uchun to'g'ri kelmaydi. Chunki fayllarda muammolar (synchronization, security va hokazo) ko'p. Hullas ular ma'lumotlar bazasi sifatida ishlatishga mo'ljallanmagan.

Shuning uchun ham mahsus ma'lumotlar bazasi o'ylab topilgan.

Ular fayl shaklida bo'lishi mumkin. Masalan SQLite. Shunda sizning dasturingiz to'g'ridan to'g'ri shu fayl shaklidagi database bilan muloqot qiladi.

Bunday databaselar kichik dasturlar uchun yaxshi qo'l kelishi mumkin. Lekin murakkab dasturlar uchun bunday ma'lumotlar bazasi to'g'ri kelmaydi.

Unday dasturlar uchun boshqa bir dastur ko'rinishidagi databaselar kerak. Bunday databaselarga PostgreSQL, MySQL va SQL Serverlarni misol qilib aytishimiz mumkin. Shunday sizning dasturingiz shu database dasturlar bilan muloqot qiladi. Bu databaselar esa o'zlarining ichida bir nechta fayllarni optimal tarzda boshqaraveradi.

Sizning dasturingiz fayllar bilan gaplashmaydi.

Ana endi savol tug'iladi. SQLite, PostgreSQL va boshqalar bilan dasturlar qanday gaplashadi? Buning uchun computer scientistlar mahsus til o'ylab topgan: SQL. Bu haqida endi boshqa postda bo'ladi.

@JakhonRakhmonBot

Clean code yozish oddiy kod yozishdan ko'ra ko'proq vaqt olsa-da, umuman olganda vaqtingizni tejaydi.

DRY, SOLID, KISS kabi prinsplarga asosan yozilgan Clean codega o'zgartirish kiritish, yangi componentlar qo'shish va o'chirish oson bo'ladi. Bo'lmasa, kodingizni tushunish va maintenance qilish qiyin bo'lib qoladi va qachondir kodingiz "legacy code"ga aylanib qoladi. Tamom. Only god knows how it works.
Clean codega 1 soatda kiritish mumkin bo'lgan o'zgarish bad codeda 1-2 kun, hatto haftalar olishi mumkin.

Commentlardan foydalaning. "Komment shart bo'lmaydigan kod yozing" degan gap yuradi*. Shaxsan men uchun bu gap faqat "Wow, cool!" deyish uchun o'ylab topilgan. Agar menga ishonmasangiz biror kattaroq texnologiya yoki projectning kodini titkilab ko'ring. Plus, agar comment shart bo'lmaganda, uni umuman o'ylab topishmasdi. Xullas, o'zingizdan keyin bu kodni o'qiydiganlarni ham o'ylang.

*Unaqalarga jazo sifatida competetive programmingda yozgan kodlarimni tushunishni bergan bo'lardim :-)

Bir uyum 🥴 kodga qarab shular haqida o'ylab qoldim.

[Meme] worky no mean goody
https://redd.it/ps1pn5

by @programmer_humor

PostgreSQL bo'yicha docsdan tashqari yaxshi manbaa izlayotganlar bormi?
Mana sizga xazina:
www.postgresqltutorial.com

P.S. PostgreSQL docs yaxshi yozilgan, lekin biroz "sovuqqon".
Bu saytdagi maqolalarni esa o'qib rohatlanasiz.

def createOrder(request):
form = OrderForm()
if request.method == 'POST':
# print('Printing POST', request.POST
form = OrderForm(request.POST)
if form.is_valid():
form.save()
return redirect('/')
context = {'form': form}
return render(request, 'accounts/order_form.html', context)

shu jarayondi oddiy qilib tushuntrib berdin tushindim lekin toliq anglab yetmadim iloji bolsa

User pagega kirgan vaqtida GET request yuborib pageni qabul qilib oladi.
Bunda form = OrderForm() degan joyi ishlab, keyingi if ishlamaydi(sababi, bizda GET request). Natijada form contextga qo'shilib, userga response qilib yuboriladi.
Demak, biz userga bo'sh form yubordik. Shu bilan birinchi request tugadi.

Endi user formni qabul qilib olgach, kerakli joylariga ma'lumot kiritib, submit qiladi.
Form action bosh turgani uchun submit qilingan natija ham shu urlga keladi, faqat bu safar POST request bo'lib.
Endi if blokining ichi bajariladi. OrderFormga bizga kelgan request ichidagi ma'lumotlarni kiritsak, u bizga python object qaytaradi. is_valid() methodi orqali esa u bizning so'ragan model classimizga(form class yozayotganda kiritgan) to'g'ri kelish yoki kelmasligi tekshiriladi. Agar to'g'ri kelsa, demak, u xavfsiz. save orqali uni databasega saqlab, bizni kutib turgan userni main pagega jo'natib yuborayapmiz.

buni bunday yozishingiz ham mumkin edi:

def createOrder(request):

if request.method == 'GET':
form = OrderForm
context = {'form': form}
return render(requst, <template>, context)

if request.method == 'POST':
...
return redirect('/')

Bir tanishim kursdoshlari bilan ingliz tilidagi ajoyib manbaani o'zbek tiliga tarjima qilishibdi.

Hali o'zim ham deyarli o'qimadim, lekin meni o'ziga tortdi. Bu yerda yaxshi coder software engineer bo'lish uchun talab qilinadigan bilimlar haqida va gigant kompaniyalarning interviewlariga qanday tayyorlanish haqida yozilgan ekan.
Qiziqqanlar uchun maqolaning originaliga link ham bor.

https://github.com/jwasham/coding-interview-university/blob/main/translations/README-uz.md

Tarjima mualliflaridan birining kanali:
@py_notes_uz

Wu model.
Bunda ticket har bir yangi news ucun yangittan ociliwi kk

Misol ucun A konsert 250ta joy bor oshandan joyni tanlab sotib olsa boladi.
Korvotgan bosela unique true qilib quyganma sitlarni.
Hozir man B konsert yaratdim undayam 250ta joy bow boliwi kk manda unaqa bomayapdi.
A konsert de egallangan joylar ham korinvotti B da nima qilsam boladi

Assalomu alaykum, yaxshi savol.
Mana bu yerda yechim ko'rsatilgan:

https://docs.djangoproject.com/en/3.2/ref/models/options/#unique-together

😅

✅ @javohir_webdev

Ba'zi dasturchilar:

CREATE TABLE girlfriend (
id BIGINT PRIMARY KEY,
name VARCHAR
);


Yana o'sha dasturchilar:

ERROR: bigint out of range.

Tushungan tushundi :-)

#uz #fun

Men:

SELECT * FROM girlfriend;

ERROR: Relation "girlfriend" does not exist.