Ngopi #85. Telung piwulang Jawa sing daksinaoni kanthi susah. Carane nggunakake prinsip SOLID ing kode

Telung Piwulang Basa Jawa Aku Sinau Cara Hard

Sumber: Media Pembelajaran Basa Jawa iku angel. Aku sinau saka kesalahanku. Saiki sampeyan uga bisa sinau saka kesalahanku lan pengalaman pahit, sing ora kudu sampeyan duwe.

1. Lambdas bisa nimbulaké alangan.

Lambdas asring ngluwihi 4 baris kode lan luwih gedhe tinimbang sing dikarepake. Iki beban memori kerja. Apa sampeyan kudu ngganti variabel saka lambda? Sampeyan ora bisa nindakake iku. Kenging punapa? Yen lambda bisa ngakses variabel situs telpon, masalah threading bisa uga muncul. Mulane sampeyan ora bisa ngganti variabel saka lambda. Nanging Happy path ing lambda bisa digunakake kanthi becik. Sawise gagal runtime, sampeyan bakal nampa respon iki:

at [CLASS].lambda$null$2([CLASS].java:85)
at [CLASS]$$Lambda$64/730559617.accept(Unknown Source)

Iku angel ngetutake jejak tumpukan lambda. Jeneng-jeneng kasebut mbingungake lan angel dilacak lan debug. More lambdas = liyane tumpukan tilak. Apa cara paling apik kanggo debug lambdas? Gunakake asil penengah.

map(elem -> {
 int result = elem.getResult();
 return result;
});

Cara liya sing apik yaiku nggunakake teknik debugging IntelliJ sing canggih. Gunakake TAB kanggo milih kode sing pengin debug lan gabungke karo asil penengah. "Nalika kita mandheg ing baris sing ngemot lambda, yen kita menet F7 (langkah menyang), banjur IntelliJ nyorot pecahan sing kudu didebug. Kita bisa ngalih blok kanggo debug nggunakake Tab, lan yen wis mutusake, penet F7 maneh. Kepiye cara ngakses variabel situs telpon saka lambda? Sampeyan mung bisa ngakses variabel final utawa bener final. Sampeyan kudu nggawe pambungkus watara variabel lokasi telpon. Salah siji nggunakake AtomicType utawa nggunakake jinis sampeyan dhewe. Sampeyan bisa ngganti pambungkus variabel sing digawe nganggo lambda. Carane ngatasi masalah tumpukan tilak? Gunakake fungsi sing dijenengi. Kanthi cara iki, sampeyan bisa kanthi cepet nemokake kode sing tanggung jawab, mriksa logika, lan ngatasi masalah. Gunakake fungsi sing dijenengi kanggo ngilangi jejak tumpukan samar. Apa lambda sing padha diulang? Selehake ing fungsi jenenge. Sampeyan bakal duwe titik referensi siji. Saben lambda entuk fungsi sing digawe, sing nggawe angel dilacak.

lambda$yourNamedFunction
lambda$0

Fungsi sing dijenengi ngrampungake masalah sing beda. Lambda gedhe. Fungsi sing dijenengi ngilangi lambdas gedhe, nggawe potongan kode sing luwih cilik, lan nggawe fungsi sing bisa dipasang.

.map(this::namedFunc1).filter(this::namedFilter1).map(this::namedFunc2)

2. Masalah karo dhaptar

Sampeyan kudu nggarap dhaptar ( Dhaptar ). Sampeyan butuh HashMap kanggo data kasebut. Kanggo peran sampeyan butuh TreeMap . Daftar terus. Lan ora ana cara sampeyan bisa nyegah nggarap koleksi. Carane nggawe dhaptar? Apa jinis dhaptar sing sampeyan butuhake? Apa kudu immutable utawa mutable? Kabeh jawaban kasebut mengaruhi masa depan kode sampeyan. Pilih dhaptar sing bener sadurunge supaya sampeyan ora getun mengko. Arrays :: asList nggawe dhaptar "end-to-end". Apa sampeyan ora bisa nindakake karo dhaptar iki? Sampeyan ora bisa ngowahi ukurane. Dheweke ora bisa diganti. Apa sampeyan bisa nindakake ing kene? Nemtokake unsur, ngurutake, utawa operasi liyane sing ora mengaruhi ukuran. Gunakake Arrays::asList kanthi ati-ati amarga ukurane ora bisa diganti nanging isine ora. ArrayList anyar () nggawe dhaptar "mutable" anyar. Operasi apa sing didhukung dhaptar sing digawe? Mekaten, lan iki minangka alesan kanggo ngati-ati. Nggawe dhaptar sing bisa diganti saka sing ora bisa diganti nggunakake ArrayList anyar () . List :: saka nggawe koleksi "ora owah". Ukuran lan isine ora owah ing kahanan tartamtu. Yen isi kasebut minangka data primitif, kayata int , dhaptar kasebut ora bisa diganti. Coba deleng conto ing ngisor iki.

@Test
public void testListOfBuilders() {
  System.out.println("### TESTING listOF with mutable content ###");

  StringBuilder one = new StringBuilder();
  one.append("a");

  StringBuilder two = new StringBuilder();
  two.append("a");

  List<StringBuilder> asList = List.of(one, two);

  asList.get(0).append("123");

  System.out.println(asList.get(0).toString());
}

Sampeyan kudu nggawe obyek sing ora bisa diganti lan nglebokake menyang List:: of . Nanging, List:: of ora menehi jaminan saka immutability. List:: saka nyedhiyakake immutability, linuwih, lan readability. Ngerti kapan nggunakake mutable lan nalika nggunakake struktur immutable. Dhaptar argumen sing ora kudu diganti kudu ana ing dhaptar sing ora bisa diganti. Dhaptar sing bisa diganti bisa dadi dhaptar sing bisa diganti. Ngerti koleksi apa sing sampeyan butuhake kanggo nggawe kode sing dipercaya.

3. Anotasi alon-alon sampeyan

Apa sampeyan nggunakake anotasi? Apa sampeyan ngerti? Apa sampeyan ngerti apa sing ditindakake? Yen sampeyan mikir yen anotasi Log cocog kanggo saben metode, sampeyan salah. Aku nggunakake Log kanggo log argumen metode. Aku kaget, ora bisa.

@Transaction
@Method("GET")
@PathElement("time")
@PathElement("date")
@Autowired
@Secure("ROLE_ADMIN")
public void manage(@Qualifier('time')int time) {
...
}

Apa salah karo kode iki? Ana akeh konfigurasi digest ing kene. Sampeyan bakal nemoni iki kaping pirang-pirang. Konfigurasi dicampur karo kode biasa. Ora ala ing dhewe, nanging keno mripat. Anotasi dibutuhake kanggo nyuda kode boilerplate. Sampeyan ora perlu nulis logika log kanggo saben titik pungkasan. Ora perlu nyetel transaksi, gunakake @Transactional . Anotasi nyuda pola kanthi ngekstrak kode. Ora ana pemenang sing jelas amarga loro-lorone ana ing game kasebut. Aku isih nggunakake XML lan anotasi. Yen sampeyan nemokake pola sing bola-bali, paling apik kanggo mindhah logika menyang anotasi. Contone, logging minangka pilihan anotasi sing apik. Moral: aja nganggo anotasi lan aja lali XML.

Bonus: Sampeyan bisa uga duwe masalah karo Opsional

Sampeyan bakal nggunakake orElse saka Opsional . Prilaku sing ora dikarepake dumadi nalika sampeyan ora ngliwati konstanta orElse . Sampeyan kudu ngerti iki kanggo nyegah masalah ing mangsa ngarep. Ayo katon ing sawetara conto. Nalika getValue(x) ngasilake nilai, getValue(y) dieksekusi . Cara ing orElse dieksekusi yen getValue(x) ngasilake nilai Opsional sing ora kosong .

getValue(x).orElse(getValue(y)
                  .orElseThrow(() -> new NotFoundException("value not present")));

public Optional<Value> getValue(Source s)
{
  System.out.println("Source: " + s.getName());

  // returns value from s source
}

// when getValue(x) is present system will output
Source: x
Source: y

Gunakake orElseGet . Ora bakal nglakokake kode kanggo Pilihan sing ora kosong .

getValue(x).orElseGet(() -> getValue(y)
                  .orElseThrow(() -> new NotFoundException("value not present")));

public Optional<Value> getValue(Source s)
{
  System.out.println("Source: " + s.getName());

  // returns value from s source
}

// when getValue(x) is present system will output
Source: x

Kesimpulan

Sinau basa Jawa iku angel. Sampeyan ora bisa sinau basa Jawa sajrone 24 jam. Ngasah katrampilan sampeyan. Njupuk wektu, sinau lan unggul ing proyek sampeyan.

Carane nggunakake prinsip SOLID ing kode

Sumber: Cleanthecode Nulis kode sing dipercaya mbutuhake prinsip SOLID. Ing sawetara titik, kita kabeh kudu sinau babagan program. Lan ayo padha jujur. Kita padha BODO. Lan kode kita padha. Alhamdulillah kita wis SOLID.

Prinsip SOLID

Dadi kepiye carane nulis kode SOLID? Iku bener prasaja. Sampeyan mung kudu tindakake limang aturan iki:

• Prinsip Tanggung Jawab Tunggal
• Prinsip mbukak-tutup
• Prinsip panggantos Liskov
• Prinsip pamisahan antarmuka
• Prinsip Inversi Dependensi

Aja kuwatir! Prinsip kasebut luwih gampang tinimbang sing katon!

Prinsip Tanggung Jawab Tunggal

Ing bukuné, Robert C. Martin njlèntrèhaké prinsip iki minangka nderek: "A kelas kudu mung siji alesan kanggo ngganti." Ayo padha ndeleng rong conto bebarengan.

1. Apa sing ora kudu ditindakake

Kita duwe kelas sing diarani Panganggo sing ngidini pangguna nindakake perkara ing ngisor iki:

• Ndhaptar akun
• mlebu
• Nampa kabar nalika pisanan sampeyan mlebu

Kelas iki saiki duwe sawetara tanggung jawab. Yen proses registrasi diganti, kelas Panganggo bakal diganti. Sing padha bakal kedadeyan yen proses login utawa proses notifikasi diganti. Iki tegese kelas wis overloaded. Kakehan kuwajibane. Cara paling gampang kanggo ndandani iki yaiku mindhah tanggung jawab menyang kelas sampeyan supaya kelas Panganggo mung tanggung jawab kanggo nggabungake kelas. Yen proses kasebut diganti, sampeyan duwe kelas sing jelas lan kapisah sing kudu diganti.

2. Apa sing kudu ditindakake

Bayangake kelas sing kudu nuduhake kabar menyang pangguna anyar, FirstUseNotification . Iku bakal kalebu telung fungsi:

• Priksa manawa kabar wis ditampilake
• Nuduhake kabar
• Tandhani kabar minangka wis ditampilake

Apa kelas iki duwe macem-macem alasan kanggo ngganti? Ora. Kelas iki nduweni fungsi sing jelas - nampilake kabar kanggo pangguna anyar. Iki tegese kelas duwe siji alesan kanggo ngganti. Yaiku, yen gol iki diganti. Dadi, kelas iki ora nglanggar prinsip tanggung jawab tunggal. Mesthi wae, ana sawetara perkara sing bisa diganti: cara notifikasi ditandhani minangka diwaca bisa uga owah, utawa cara kabar katon. Nanging, amarga tujuan kelas kasebut jelas lan dhasar, iki pancen apik.

Prinsip mbukak-tutup

Prinsip open-closed diciptakake dening Bertrand Meyer: "Obyek piranti lunak (kelas, modul, fungsi, lan sapiturute) kudu mbukak kanggo ekstensi, nanging ditutup kanggo modifikasi." Prinsip iki pancen prasaja banget. Sampeyan kudu nulis kode supaya fitur anyar bisa ditambahake tanpa ngganti kode sumber. Iki mbantu nyegah kahanan sampeyan kudu ngganti kelas sing gumantung ing kelas sing diowahi. Nanging, prinsip iki luwih angel ditindakake. Meyer nyaranake nggunakake warisan. Nanging ndadékaké kanggo sambungan kuwat. Kita bakal ngrembug babagan iki ing Prinsip Pemisahan Antarmuka lan Prinsip Inversi Dependensi. Dadi Martin teka karo pendekatan sing luwih apik: nggunakake polimorfisme. Tinimbang warisan konvensional, pendekatan iki nggunakake kelas dhasar abstrak. Kanthi cara iki, spesifikasi warisan bisa digunakake maneh nalika implementasine ora dibutuhake. Antarmuka bisa ditulis sapisan banjur ditutup kanggo nggawe pangowahan. Fungsi anyar banjur kudu ngleksanakake antarmuka iki lan ngluwihi.

Prinsip panggantos Liskov

Prinsip iki diciptakake dening Barbara Liskov, pemenang Turing Award kanggo kontribusi kanggo basa pemrograman lan metodologi piranti lunak. Ing artikel kasebut, dheweke nemtokake prinsip kasebut kaya mangkene: "Obyek ing program kudu diganti karo conto subtipe tanpa mengaruhi eksekusi program sing bener." Ayo ndeleng prinsip iki minangka programmer. Mbayangno kita duwe kothak. Bisa dadi persegi dowo, sing muni logis amarga kothak minangka wangun khusus saka persegi dowo. Iki ngendi prinsip panggantos Liskov teka kanggo ngluwari. Nang endi wae sampeyan bakal nyana kanggo ndeleng persegi dowo ing kode, iku uga bisa kanggo kothak katon. Saiki bayangake persegi panjang sampeyan duwe metode SetWidth lan SetHeight . Iki tegese kothak uga mbutuhake cara kasebut. Sayange, iki ora ana gunane. Iki tegese prinsip panggantos Liskov dilanggar ing kene.

Prinsip pamisahan antarmuka

Kaya kabeh prinsip, prinsip pamisahan antarmuka luwih gampang tinimbang sing katon: "Akeh antarmuka khusus klien luwih apik tinimbang antarmuka tujuan umum." Minangka prinsip tanggung jawab tunggal, tujuane yaiku nyuda efek samping lan jumlah owah-owahan sing dibutuhake. Mesthi, ora ana sing nulis kode kasebut kanthi sengaja. Nanging gampang ditemoni. Elinga kothak saka prinsip sadurunge? Saiki bayangake yen kita mutusake kanggo ngetrapake rencana kita: kita ngasilake kothak saka persegi dowo. Saiki kita meksa kothak kanggo ngleksanakake setWidth lan setHeight , sing mbokmenawa ora nindakake apa-apa. Yen padha nindakake iku, kita mbokmenawa bakal break soko amarga jembaré lan dhuwur ora bakal kita samesthine. Untunge kanggo kita, iki tegese kita ora nglanggar prinsip substitusi Liskov, amarga saiki ngidini panggunaan kothak ing ngendi wae nggunakake persegi dowo. Nanging, iki nggawe masalah anyar: kita saiki nglanggar prinsip pamisahan antarmuka. We meksa kelas asale kanggo ngleksanakake fungsi sing milih ora kanggo nggunakake.

Prinsip Inversi Dependensi

Prinsip pungkasan iku prasaja: modul tingkat dhuwur kudu bisa digunakake maneh lan ora kena pengaruh owah-owahan ing modul tingkat rendah.

• A. modul tingkat dhuwur ngirim ora gumantung ing modul tingkat kurang. Loro-lorone kudu gumantung ing abstraksi (kayata antarmuka).
• B. Abstraksi ngirim ora gumantung ing rincian. Rincian (implementasi konkrit) kudu gumantung saka abstraksi.

Iki bisa digayuh kanthi ngetrapake abstraksi sing misahake modul tingkat dhuwur lan rendah. Jeneng prinsip kasebut nuduhake manawa arah ketergantungan diganti, nanging ora kaya ngono. Iku mung misahake dependensi kanthi ngenalake abstraksi ing antarane. Akibaté, sampeyan bakal entuk rong dependensi:

• Modul tingkat dhuwur, gumantung saka abstraksi
• Modul tingkat rendah gumantung saka abstraksi sing padha

Iki bisa uga katon angel, nanging nyatane kedadeyan kanthi otomatis yen sampeyan nggunakake prinsip mbukak / ditutup lan prinsip substitusi Liskov. Iku kabeh! Sampeyan saiki wis sinau limang prinsip inti sing ndhukung SOLID. Kanthi limang prinsip iki, sampeyan bisa nggawe kode sampeyan apik tenan!