JavaRush /Java blogi /Random-UZ /Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar ...

Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha

Guruhda nashr etilgan
Hammaga xayrli kun: bugun men siz bilan kodni to'g'ri yozish haqida gaplashmoqchiman. Men dasturlashni birinchi marta boshlaganimda, hech qayerda bunday yozish mumkinligi aniq yozilmagan, agar siz shunday yozsangiz, men sizni topaman va .... Natijada miyamda juda ko'p savollar paydo bo'ldi: qanday qilib to'g'ri yozish kerak, dasturning u yoki bu bo'limida qanday tamoyillarga amal qilish kerak va hokazo. Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 1To'g'ri, hamma ham "Clean Code" kabi kitoblarga darhol sho'ng'ishni xohlamaydi, chunki ularda juda ko'p narsa yozilgan, lekin dastlab juda oz narsa aniq. Va o'qishni tugatgandan so'ng, siz kodlash istagini so'ndirishingiz mumkin. Shunday qilib, yuqoridagilarga asoslanib, bugun men sizga yuqori darajadagi kod yozish uchun kichik qo'llanma (kichik tavsiyalar to'plami) bilan ta'minlamoqchiman. Ushbu maqolada biz tizim yaratish va interfeyslar, sinflar va ob'ektlar bilan ishlash bilan bog'liq asosiy qoidalar va tushunchalarni ko'rib chiqamiz. Ushbu materialni o'qish sizga ko'p vaqt talab qilmaydi va umid qilamanki, zerikishingizga yo'l qo'ymaydi. Men yuqoridan pastga, ya'ni ilovaning umumiy tuzilishidan aniqroq tafsilotlarga o'taman. Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 2

Tizim

Tizimning umumiy talab qilinadigan xususiyatlari quyidagilardan iborat:
  • minimal murakkablik - haddan tashqari murakkab loyihalardan qochish kerak. Asosiysi, oddiylik va ravshanlik (eng yaxshisi = oddiy);
  • texnik xizmat ko'rsatish qulayligi - dasturni yaratishda siz uni qo'llab-quvvatlash kerakligini yodda tutishingiz kerak (hatto u siz bo'lmasangiz ham), shuning uchun kod aniq va ravshan bo'lishi kerak;
  • zaif bog'lanish - dasturning turli qismlari orasidagi ulanishlarning minimal soni (OOP tamoyillaridan maksimal foydalanish);
  • qayta foydalanish imkoniyati - uning qismlarini boshqa ilovalarda qayta ishlatish imkoniyatiga ega tizimni loyihalash;
  • portativlik - tizim boshqa muhitga osongina moslashtirilishi kerak;
  • yagona uslub - tizimni uning turli qismlarida yagona uslubda loyihalash;
  • kengaytirilishi (miqyosidagi) - tizimni uning asosiy tuzilishini buzmasdan takomillashtirish (agar siz parcha qo'shsangiz yoki o'zgartirsangiz, bu qolganlarga ta'sir qilmasligi kerak).
Funktsiyani qo'shmasdan, o'zgartirishni talab qilmaydigan dasturni yaratish deyarli mumkin emas. Farzandimiz zamon bilan hamnafas bo'lishi uchun biz doimo yangi elementlarni kiritishimiz kerak bo'ladi. Va bu erda ölçeklenebilirlik o'ynaydi . Masshtablilik mohiyatan dasturni kengaytirish, yangi funksiyalarni qo'shish, ko'proq resurslar bilan ishlash (yoki boshqacha qilib aytganda, ko'proq yuk bilan). Ya'ni, biz ba'zi qoidalarga rioya qilishimiz kerak, masalan, modullikni oshirish orqali tizimning ulanishini kamaytirish, yangi mantiqni qo'shish osonroq bo'ladi.

Tizimni loyihalash bosqichlari

  1. Dasturiy ta'minot tizimi - ilovani umumiy shaklda loyihalash.
  2. Quyi tizimlarga/paketlarga ajratish - mantiqiy ravishda ajratiladigan qismlarni aniqlash va ular o'rtasidagi o'zaro ta'sir qoidalarini aniqlash.
  3. Quyi tizimlarni sinflarga bo'lish - tizim qismlarini muayyan sinflar va interfeyslarga bo'lish, shuningdek ular orasidagi o'zaro ta'sirni aniqlash.
  4. Sinflarni metodlarga bo'lish bu sinfning vazifasidan kelib chiqib, sinf uchun zarur bo'lgan usullarning to'liq ta'rifidir. Usulni loyihalash - individual usullarning funksionalligini batafsil aniqlash.
Odatda, oddiy ishlab chiquvchilar dizayn uchun mas'uldirlar va dastur me'mori yuqorida tavsiflangan narsalar uchun javobgardir.

Tizimni loyihalashning asosiy tamoyillari va tushunchalari

Lazy initsializatsiya idiomasi Ilova foydalanilmaguncha ob'ekt yaratishga vaqt sarflamaydi, bu ishga tushirish jarayonini tezlashtiradi va axlat yig'uvchi yukni kamaytiradi. Lekin bu bilan juda uzoqqa bormaslik kerak, chunki bu modullikning buzilishiga olib kelishi mumkin. Dizaynning barcha bosqichlarini ma'lum bir qismga, masalan, asosiy yoki zavod kabi ishlaydigan sinfga ko'chirishga arziydi . Yaxshi kodning jihatlaridan biri tez-tez takrorlanadigan, qozonxona kodining yo'qligi. Qoidaga ko'ra, bunday kod kerakli vaqtda chaqirilishi uchun alohida sinfga joylashtiriladi. AOP Aspektga yo'naltirilgan dasturlashni alohida ta'kidlamoqchiman . Bu end-to-end mantiqni kiritish orqali dasturlash, ya'ni takrorlanuvchi kod sinflarga - aspektlarga qo'yiladi va ma'lum shartlarga erishilganda chaqiriladi. Masalan, ma'lum bir nomli usulga kirishda yoki ma'lum turdagi o'zgaruvchiga kirishda. Ba'zida jihatlar chalkash bo'lishi mumkin, chunki kod qaerdan chaqirilganligi darhol aniq emas, ammo shunga qaramay, bu juda foydali funksionallik. Xususan, keshlash yoki jurnalga kirishda: biz ushbu funksiyani oddiy sinflarga qo'shimcha mantiq qo'shmasdan qo'shamiz. OAP haqida ko'proq ma'lumotni bu erda o'qishingiz mumkin . Kent Bek bo'yicha oddiy arxitekturani loyihalashning 4 qoidasi
  1. Ekspressivlik - sinfning aniq ifodalangan maqsadiga bo'lgan ehtiyoj, to'g'ri nomlash, kichik o'lcham va yagona javobgarlik tamoyiliga rioya qilish orqali erishiladi (buni quyida batafsilroq ko'rib chiqamiz).
  2. Minimal sinflar va usullar - sinflarni imkon qadar kichik va bir yo'nalishga ajratish istagida siz juda uzoqqa borishingiz mumkin (antipattern - o'q otish). Ushbu tamoyil tizimni ixcham saqlashni va juda uzoqqa bormaslikni, har bir aksirish uchun sinf yaratishni talab qiladi.
  3. Takrorlashning yo'qligi - chalkashtirib yuboradigan qo'shimcha kod tizimning yomon dizayni belgisidir va alohida joyga ko'chiriladi.
  4. Barcha testlarning bajarilishi - barcha testlardan o'tgan tizim nazorat qilinadi, chunki har qanday o'zgarish testlarning muvaffaqiyatsiz bo'lishiga olib kelishi mumkin, bu bizga usulning ichki mantig'idagi o'zgarish ham kutilgan xatti-harakatlarning o'zgarishiga olib kelganligini ko'rsatishi mumkin.
SOLID Tizimni loyihalashda SOLID ning taniqli tamoyillarini hisobga olish kerak: S - yagona javobgarlik - yagona javobgarlik printsipi; O - ochiq-yopiq - ochiqlik/yaqinlik tamoyili; L - Liskov almashtirish - Barbara Liskovning almashtirish printsipi; I - interfeyslarni ajratish - interfeyslarni ajratish printsipi; D - qaramlik inversiyasi - bog'liqlik inversiyasi printsipi; Biz har bir tamoyilga alohida to‘xtalib o‘tmaymiz (bu maqola doirasidan biroz tashqarida, lekin bu yerda ko‘proq ma’lumot olishingiz mumkin.

Interfeys

Ehtimol, adekvat sinfni yaratishning eng muhim bosqichlaridan biri bu sinfning amalga oshirish tafsilotlarini yashiradigan yaxshi abstraksiyani ifodalovchi va shu bilan birga bir-biriga aniq mos keladigan usullar guruhini ifodalovchi adekvat interfeysni yaratishdir. . Keling, SOLID tamoyillaridan birini batafsil ko'rib chiqaylik - interfeyslarni ajratish : mijozlar (sinflar) o'zlari foydalanmaydigan keraksiz usullarni qo'llamasliklari kerak. Ya'ni, agar biz ushbu interfeysning yagona vazifasini bajarishga qaratilgan minimal miqdordagi usullar bilan interfeyslarni yaratish haqida gapiradigan bo'lsak (men uchun bu bitta mas'uliyatga juda o'xshaydi ), bir nechta kichikroq narsalarni yaratish yaxshiroqdir. bir shishgan interfeys o'rniga birlar. Yaxshiyamki, merosda bo'lgani kabi, sinf bir nechta interfeyslarni amalga oshirishi mumkin. Bundan tashqari, interfeyslarni to'g'ri nomlash haqida eslab qolishingiz kerak: nom uning vazifasini iloji boricha aniq aks ettirishi kerak. Va, albatta, u qanchalik qisqa bo'lsa, chalkashliklar shunchalik kam bo'ladi. Hujjatlar uchun sharhlar odatda interfeys darajasida yoziladi , bu esa, o'z navbatida, usul nima qilish kerakligini, qanday argumentlarni talab qilishini va u nimani qaytarishini batafsil tasvirlab berishga yordam beradi.

Sinf

Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 3Keling, darslarning ichki tashkil etilishini ko'rib chiqaylik. To'g'rirog'i, sinflarni qurishda amal qilish kerak bo'lgan ba'zi qarashlar va qoidalar. Odatda, sinf ma'lum bir tartibda joylashtirilgan o'zgaruvchilar ro'yxatidan boshlanishi kerak:
  1. umumiy statik konstantalar;
  2. xususiy statik konstantalar;
  3. xususiy misol o'zgaruvchilari.
Keyingi argumentlar sonidan ko'piga qarab turli konstruktorlar. Ulardan keyin ochiqroq kirishdan eng yopiq usullargacha bo'lgan usullar mavjud: qoida tariqasida, biz cheklamoqchi bo'lgan ba'zi funktsiyalarni amalga oshirishni yashiradigan xususiy usullar eng quyida joylashgan.

Sinf hajmi

Endi men sinf hajmi haqida gapirmoqchiman. Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 4Keling, SOLID tamoyillaridan birini eslaylik - yagona mas'uliyat . Yagona javobgarlik - yagona javobgarlik tamoyili. Unda aytilishicha, har bir ob'ektning faqat bitta maqsadi (mas'uliyati) bor va uning barcha usullarining mantig'i uni ta'minlashga qaratilgan. Ya'ni, shunga asoslanib, biz katta, shishgan sinflardan qochishimiz kerak (bu o'z tabiatiga ko'ra antipattern - "ilohiy ob'ekt") va agar bizda sinfda turli xil, heterojen mantiq usullari ko'p bo'lsa, biz o'ylashimiz kerak. uni bir nechta mantiqiy qismlarga (sinflarga) ajratish haqida. Bu, o'z navbatida, kodni o'qish qobiliyatini yaxshilaydi, chunki agar biz berilgan sinfning taxminiy maqsadini bilsak, usulning maqsadini tushunish uchun ko'p vaqt kerak emas. Bundan tashqari , sinf nomini kuzatib borishingiz kerak : u o'z ichiga olgan mantiqni aks ettirishi kerak. Aytaylik, agar nomi 20+ so'zdan iborat bo'lgan sinfimiz bo'lsa, biz refaktoring haqida o'ylashimiz kerak. Har bir o'zini hurmat qiladigan sinfda bunday ko'p sonli ichki o'zgaruvchilar bo'lmasligi kerak. Darhaqiqat, har bir usul ulardan biri yoki bir nechtasi bilan ishlaydi, bu sinf ichida ko'proq bog'lanishga olib keladi (bu aynan shunday bo'lishi kerak, chunki sinf bir butun bo'lishi kerak). Natijada, sinfning uyg'unligini oshirish uning kamayishiga olib keladi va, albatta, bizning sinflar soni ko'payadi. Ba'zilar uchun bu zerikarli; ular muayyan katta vazifa qanday ishlashini ko'rish uchun sinfga ko'proq borishlari kerak. Boshqa narsalar bilan bir qatorda, har bir sinf boshqalar bilan minimal darajada bog'lanishi kerak bo'lgan kichik moduldir. Ushbu izolyatsiya sinfga qo'shimcha mantiq qo'shganda qilishimiz kerak bo'lgan o'zgarishlar sonini kamaytiradi.

Ob'ektlar

Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 5

Inkapsulyatsiya

Bu erda biz birinchi navbatda OOP tamoyillaridan biri haqida gapiramiz - kapsülleme . Shunday qilib, amalga oshirishni yashirish o'zgaruvchilar o'rtasida usul qatlamini yaratishga tushmaydi (bitta usullar, qabul qiluvchilar va sozlagichlar orqali kirishni o'ylamasdan cheklash, bu yaxshi emas, chunki butun inkapsulyatsiya nuqtasi yo'qoladi). Kirishni yashirish abstraktsiyalarni shakllantirishga qaratilgan, ya'ni sinf umumiy aniq usullarni taqdim etadi, ular orqali biz ma'lumotlarimiz bilan ishlaymiz. Ammo foydalanuvchi bu ma'lumotlar bilan qanday ishlashimizni bilishi shart emas - u ishlaydi va bu yaxshi.

Demeter qonuni

Siz Demeter qonunini ham ko'rib chiqishingiz mumkin: bu sinf va uslub darajasida murakkablikni boshqarishga yordam beradigan kichik qoidalar to'plami. CarShunday qilib, bizda ob'ekt bor va uning usuli bor deb faraz qilaylik - move(Object arg1, Object arg2). Demeter qonuniga ko'ra, bu usul qo'ng'iroq qilish bilan cheklangan:
  • ob'ektning o'zi usullari Car(boshqacha aytganda, bu);
  • da yaratilgan ob'ektlar usullari move;
  • argument sifatida o'tgan ob'ektlar usullari - arg1, arg2;
  • ichki ob'ektlarning usullari Car(xuddi shu).
Boshqacha qilib aytganda, Demeter qonuni bolalar qoidasiga o'xshaydi - siz do'stlaringiz bilan gaplashishingiz mumkin, lekin begonalar bilan emas .

Ma'lumotlar tuzilishi

Ma'lumotlar strukturasi - bu o'zaro bog'liq elementlarning to'plami. Ob'ektni ma'lumotlar strukturasi sifatida ko'rib chiqishda bu usullar bilan qayta ishlanadigan ma'lumotlar elementlari to'plami bo'lib, ularning mavjudligi bevosita nazarda tutilgan. Ya'ni, bu ob'ekt bo'lib, uning maqsadi saqlangan ma'lumotlarni saqlash va ishlatish (qayta ishlash). Oddiy ob'ektdan asosiy farq shundaki, ob'ekt mavjudligi nazarda tutilgan ma'lumotlar elementlarida ishlaydigan usullar to'plamidir. Tushundingizmi? Muntazam ob'ektda asosiy jihat usullardir va ichki o'zgaruvchilar ularning to'g'ri ishlashiga qaratilgan, ammo ma'lumotlar tuzilmasida buning aksi: usullar bu erda asosiy bo'lgan saqlangan elementlar bilan ishlashni qo'llab-quvvatlaydi va yordam beradi. Ma'lumotlar strukturasi turlaridan biri Ma'lumotlarni uzatish ob'ektidir (DTO) . Bu umumiy oʻzgaruvchilarga ega sinf boʻlib, maʼlumotlar bazalari bilan ishlashda maʼlumotlarni uzatuvchi, rozetkalardan olingan xabarlarni tahlil qilish bilan ishlovchi va hokazo usullari (yoki faqat oʻqish/yozish usullari) mavjud emas. Odatda, bunday obyektlardagi maʼlumotlar uzoq vaqt saqlanmaydi va deyarli darhol bizning ilovamiz ishlaydigan ob'ektga aylantirildi. Ob'ekt, o'z navbatida, ma'lumotlar tuzilmasi hamdir, lekin uning maqsadi dasturning turli darajalarida biznes mantig'ida ishtirok etishdir, DTO esa ma'lumotlarni ilovaga/ilovadan tashishdir. Misol DTO:
@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}
Hamma narsa aniq ko'rinadi, lekin bu erda biz duragaylarning mavjudligi haqida bilib olamiz. Gibridlar - muhim mantiqni boshqarish va ichki elementlarni saqlash usullari va ularga kirish usullarini (olish/o'rnatish) o'z ichiga olgan ob'ektlar. Bunday ob'ektlar tartibsiz va yangi usullarni qo'shishni qiyinlashtiradi. Siz ulardan foydalanmasligingiz kerak, chunki ular nima uchun mo'ljallanganligi aniq emas - elementlarni saqlash yoki biron bir mantiqni bajarish. Ob'ektlarning mumkin bo'lgan turlari haqida bu erda o'qishingiz mumkin .

O'zgaruvchilarni yaratish tamoyillari

Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 6Keling, o'zgaruvchilar haqida bir oz o'ylab ko'raylik, aniqrog'i, ularni yaratish tamoyillari qanday bo'lishi mumkinligi haqida o'ylaymiz:
  1. Ideal holda, siz o'zgaruvchini ishlatishdan oldin darhol e'lon qilishingiz va ishga tushirishingiz kerak (uni yaratish va unutish o'rniga).
  2. Iloji bo'lsa, o'zgaruvchilarni ishga tushirilgandan so'ng ularning qiymati o'zgarishiga yo'l qo'ymaslik uchun yakuniy deb e'lon qiling.
  3. Hisoblagich o'zgaruvchilari haqida unutmang (odatda biz ularni qandaydir tsiklda ishlatamiz for, ya'ni ularni qayta tiklashni unutmasligimiz kerak, aks holda bu bizning butun mantiqimizni buzishi mumkin).
  4. Konstruktorda o'zgaruvchilarni ishga tushirishga harakat qilishingiz kerak.
  5. Agar ob'ektni havolali yoki havolasiz ishlatish o'rtasida tanlov mavjud bo'lsa ( new SomeObject()), holda ( ) ni tanlang, chunki bir marta foydalanilgan ushbu ob'ekt keyingi axlat yig'ish paytida o'chiriladi va resurslarni isrof qilmaydi.
  6. O'zgaruvchilarning ishlash muddatini iloji boricha qisqaroq qiling (o'zgaruvchini yaratish va oxirgi kirish o'rtasidagi masofa).
  7. Loopda ishlatiladigan o'zgaruvchilarni tsiklni o'z ichiga olgan usulning boshida emas, balki tsikldan oldin darhol boshlang.
  8. Har doim eng cheklangan doiradan boshlang va uni faqat kerak bo'lganda kengaytiring (o'zgaruvchini iloji boricha mahalliy qilishga harakat qilishingiz kerak).
  9. Har bir o'zgaruvchidan faqat bitta maqsadda foydalaning.
  10. Yashirin ma'noga ega o'zgaruvchilardan saqlaning (o'zgaruvchi ikkita vazifa o'rtasida yirtilgan, ya'ni uning turi ulardan birini hal qilish uchun mos emas).
Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 7

Usullari

Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 8Keling, to'g'ridan-to'g'ri mantiqimizni amalga oshirishga, ya'ni usullarga o'taylik.
  1. Birinchi qoida - bu ixchamlik. Ideal holda, bitta usul 20 qatordan oshmasligi kerak, shuning uchun, aytaylik, ommaviy usul sezilarli darajada "shishib ketsa", ajratilgan mantiqni shaxsiy usullarga o'tkazish haqida o'ylashingiz kerak.

  2. ifIkkinchi qoida shundaki , else, va hokazo buyruqlardagi bloklar whileyuqori darajada joylashtirilmasligi kerak: bu kodning o'qilishini sezilarli darajada kamaytiradi. Ideal holda, uyalar ikki blokdan oshmasligi kerak {}.

    Shuningdek, ushbu bloklardagi kodni ixcham va sodda qilish tavsiya etiladi.

  3. Uchinchi qoida - usul faqat bitta operatsiyani bajarishi kerak. Ya'ni, agar usul murakkab, xilma-xil mantiqni bajarsa, biz uni kichik usullarga ajratamiz. Natijada, usulning o'zi jabha bo'ladi, uning maqsadi boshqa barcha operatsiyalarni to'g'ri tartibda chaqirishdir.

    Ammo operatsiya alohida usul yaratish uchun juda oddiy ko'rinsa-chi? Ha, ba'zida bu to'pdan chumchuqlarni otish kabi ko'rinishi mumkin, ammo kichik usullar bir qator afzalliklarni beradi:

    • kodni o'qishni osonlashtiradi;
    • usullar rivojlanish jarayonida murakkablashadi va agar usul dastlab oddiy bo'lsa, uning funksionalligini murakkablashtirish biroz osonroq bo'ladi;
    • amalga oshirish tafsilotlarini yashirish;
    • kodni qayta ishlatishni osonlashtirish;
    • yuqori kod ishonchliligi.
  4. Pastga yo'naltirilgan qoida shundaki , kod yuqoridan pastga o'qilishi kerak: qanchalik past bo'lsa, mantiq chuqurligi qanchalik katta bo'lsa va aksincha, qanchalik baland bo'lsa, usullar mavhumroq bo'ladi. Misol uchun, almashtirish buyruqlari juda ixcham va istalmagan, ammo agar siz kalitni ishlatmasdan qila olmasangiz, uni iloji boricha pastroq, eng past darajadagi usullarga o'tkazishga harakat qilishingiz kerak.

  5. Usul argumentlari - qancha ideal? Ideal holda, umuman yo'q)) Lekin bu haqiqatan ham sodir bo'ladimi? Biroq, siz ulardan imkon qadar kamroq bo'lishga harakat qilishingiz kerak, chunki ular qanchalik kam bo'lsa, bu usuldan foydalanish osonroq va uni sinab ko'rish osonroq bo'ladi. Agar shubhangiz bo'lsa, kirish argumentlari ko'p bo'lgan usuldan foydalanishning barcha stsenariylarini taxmin qilishga harakat qiling.

  6. Alohida, men kirish argumenti sifatida mantiqiy bayroqqa ega bo'lgan usullarni ta'kidlamoqchiman , chunki bu tabiiy ravishda bu usul bir nechta operatsiyalarni amalga oshirishini anglatadi (agar rost bo'lsa, bitta, noto'g'ri - boshqa). Yuqorida yozganimdek, bu yaxshi emas va iloji bo'lsa, undan qochish kerak.

  7. Agar usulda juda ko'p kiruvchi argumentlar bo'lsa (ekstremal qiymat 7, lekin bu haqda 2-3 dan keyin o'ylab ko'rishingiz kerak), ba'zi argumentlarni alohida ob'ektda guruhlashingiz kerak.

  8. Agar bir nechta shunga o'xshash usullar mavjud bo'lsa (ortiqcha yuklangan) , unda o'xshash parametrlar bir xil tartibda o'tkazilishi kerak: bu o'qish va foydalanish qulayligini oshiradi.

  9. Parametrlarni usulga o'tkazganingizda, ularning barchasi ishlatilishiga ishonchingiz komil bo'lishi kerak, aks holda argument nima uchun? Uni interfeysdan kesib tashlang va hammasi shu.

  10. try/catchBu o'z tabiatiga ko'ra unchalik yoqimli emas, shuning uchun uni oraliq alohida usulga (istisnolarni hal qilish usuli) o'tkazish yaxshi harakat bo'ladi:

    public void exceptionHandling(SomeObject obj) {
        try {
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
Men yuqorida kodni takrorlash haqida gapirdim, lekin uni shu yerga qo'shaman: Agar bizda kod qismlarini takrorlash bilan bir nechta usullar mavjud bo'lsa, biz uni alohida usulga o'tkazishimiz kerak, bu usulning ham ixchamligini oshiradi. sinf. Va to'g'ri nomlar haqida unutmang. Maqolaning keyingi qismida sinflar, interfeyslar, usullar va o'zgaruvchilarning to'g'ri nomlanishi haqida batafsil ma'lumot beraman. Va bugun menda bor narsa shu. Kod yozish qoidalari: tizim yaratishdan tortib ob'ektlar bilan ishlashgacha - 9Kod qoidalari: to'g'ri nomlash kuchi, yaxshi va yomon sharhlar
Izohlar
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION