Pendahuluan

Robert L. Glass berpendapat bahwa praktik lebih dulu daripada teori. Terutama dalam pengembangan perangkat lunak, praktik mendahului teori, dan pengembang memperoleh manfaat paling banyak saat mereka terlibat dalam kode konkret. Oleh karena itu, kita akan mengesampingkan teori dan konsep untuk sementara waktu dan melihat program sederhana.

Menerapkan Aplikasi Penjualan Tiket

• Kami berencana untuk menyelenggarakan acara kecil untuk mempromosikan teater kecil.
  • Konten acara: Mengirimkan undangan kepada penonton yang dipilih melalui undian untuk menonton pertunjukan secara gratis.
• Penonton yang memenangkan undian dan yang tidak harus dipisahkan.
  • Penonton yang memenangkan undian: Menukarkan undangan dengan tiket.
  • Penonton yang tidak memenangkan undian: Membeli tiket dengan uang.

Kode praktik: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

Apa Masalahnya?

Robert Martin menjelaskan tentang tiga fungsi yang harus dimiliki modul perangkat lunak (terlepas dari ukurannya, seperti kelas, paket, atau perpustakaan yang merupakan elemen program apa pun).

• Bekerja dengan baik saat dijalankan.
• Ada untuk perubahan.
  • Perubahan harus dilakukan dengan mudah.
• Berkomunikasi dengan orang yang membaca kode.
  • Pengembang harus dapat dengan mudah membaca dan memahami.

Aplikasi penjualan tiket sebelumnya memenuhi kendala pertama, yaitu bekerja dengan baik saat dijalankan, tetapi tidak memenuhi tujuan kemampuan perubahan dan komunikasi.

Kode yang Tidak Sesuai Ekspektasi

Mari kita lihat mengapa tujuan komunikasi tidak terpenuhi.

• Apa yang dilakukan metode enter() dari kelas Theater
  • Teater melihat ke dalam tas penonton untuk melihat apakah ada undangan di dalamnya.
  • Jika ada undangan di dalam tas, teater memberi tahu penjual tiket untuk memindahkan tiket yang disimpan di loket tiket ke dalam tas penonton.
  • Jika tidak ada undangan di dalam tas, teater mengeluarkan uang tunai dari tas penonton sejumlah harga tiket, membeli tiket, dan memasukkan tiket ke dalam tas.
• Dari sudut pandang penonton, mereka harus menyaksikan pihak ketiga, teater, mengutak-atik tas mereka secara sewenang-wenang, mengambil uang, dan memasukkan tiket.
• Dari sudut pandang penjual tiket, mereka harus menyaksikan pihak ketiga, teater, memanipulasi nilai tiket dan uang tunai di loket tiket tanpa izin.
• Kode yang dapat dipahami berarti kode yang tidak menyimpang terlalu jauh dari ekspektasi kita, dan teater di atas tidak sesuai dengan ekspektasi kita.
  • Penonton harus mengeluarkan uang tunai dari tas mereka sendiri dan membayar penjual tiket untuk menerima tiket.
  • Penjual tiket harus mengambil tiket langsung dari loket tiket dan menyerahkannya kepada penonton, dan menerima uang dari penonton untuk disimpan di loket tiket.
• Selain itu, untuk memahami metode enter(), Anda harus mengingat banyak detail.
  • Audience memiliki Bag.
  • Bag berisi uang tunai dan tiket.
  • TiketSellet menjual tiket di TicketOffice, dan TicketOffice menyimpan uang dan tiket.

Kode yang Rentan Terhadap Perubahan

Metode enter() membuat 2 asumsi.

• Penonton selalu membawa tas untuk menyimpan uang tunai dan undangan.
• Penjual tiket hanya menjual tiket di loket tiket.

Bagaimana dengan skenario di bawah ini?

• Penonton mungkin tidak memiliki tas.
• Penonton dapat menggunakan kartu kredit bukan uang tunai.
• Penjual tiket dapat menjual tiket di luar loket tiket.

Misalnya, untuk memenuhi persyaratan pertama, kita harus menghapus objek Bag dari Audience dan mengubah metode enter() dari kelas Theater. Ini karena kelas Theater terlalu bergantung pada fakta bahwa penonton memiliki tas dan penjual tiket hanya menjual tiket di loket tiket. Jika salah satu fakta detail ini berubah, kita harus mengubah kelas terkait dan kelas yang bergantung padanya (misalnya, Theater).

Ini adalah masalah yang terkait dengan dependensi antar objek, dan dependensi mengimplikasikan dampak perubahan. Namun, desain berorientasi objek bertujuan untuk membangun komunitas objek yang bekerja sama satu sama lain dengan bergantung satu sama lain, jadi kita harus mempertahankan minimal dependensi yang diperlukanuntuk mengimplementasikan fungsi aplikasi dan menghapus dependensi yang tidak perlu.

Tingkat dependensi yang berlebihan antara objek disebuttingkat kopling yang tinggi, dan semakin tinggi tingkat kopling antara dua objek, semakin tinggi kemungkinan mereka akan berubah bersama. Oleh karena itu, tujuan desain adalah untuk mengurangi tingkat kopling antar objek agar desain lebih mudah diubah.

Meningkatkan Desain

Teater tidak perlu tahu bahwa penonton memiliki tas dan penjual tiket menjual tiket di loket tiket. Yang diinginkan oleh Teater hanyalah penonton memasuki teater. Oleh karena itu, penonton harus dibuat menjadi entitas yang otonom yang dapat menangani uang tunai dan undangan di tas mereka sendiri, dan penjual tiket harus dapat menangani tiket dan biaya penjualan di loket tiket mereka sendiri.

Meningkatkan Otonomi

Objek yang melakukan hanya tugas-tugas yang terkait erat dan mendelegasikan tugas-tugas yang tidak terkait ke objek lain disebut memiliki kohesi yang tinggi. Dengan membuat objek yang otonom yang menangani data mereka sendiri, kita dapat mengurangi kopling dan meningkatkan kohesi.

Berorientasi Prosedur dan Berorientasi Objek

• Berorientasi Prosedur
  • Metode enter() di Theater adalah proses, dan Audience, TicketSeller, Bag, TicketOffice adalah data.
  • Pemrograman berorientasi prosedur adalah pendekatan untuk menempatkan proses dan data dalam modul yang terpisah.
  • Ada banyak kode yang bertentangan dengan intuisi kita. (misalnya, penonton mengelola uang dan undangan mereka sendiri).
  • Sulit untuk mempersempit dampak perubahan data.
  • Tanggung jawab dikelola secara terpusat. (Teater mengelola semuanya)
• Berorientasi Objek
  • Pemrograman berorientasi objek adalah pendekatan untuk menempatkan proses dan data di dalam modul yang sama.
  • Kita dapat menulis kode yang sesuai dengan intuisi kita.
  • Dampak perubahan data dapat dipersempit secara efektif melalui enkapsulasi.
  • Setiap objek bertanggung jawab atas dirinya sendiri.
  • 
    

Kode praktik: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Masih Bisa Ditingkatkan

• Kelas Bag di kelas Audience masih merupakan entitas pasif yang ditarik oleh kelas Audience, jadi kita harus membuat kelas Bag menjadi objek yang otonom.
• TicketOffice di kelas TicketSeller juga dikelola secara sewenang-wenang oleh TicketSeller. Kita harus membuat TicketOffice menjadi objek yang otonom.
  • Namun, setelah perubahan, TicketOffice memiliki ketergantungan tambahan pada Audience.
  • Seperti ini, desain harus mempertimbangkan trade-off. Dalam kasus ini, kita dapat menyetujui untuk membuat TicketOffice menjadi objek pasif sampai batas tertentu untuk mengurangi ketergantungan pada Audience.

Kode praktik: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

Ya, Itu Bohong!

• Meskipun dalam kehidupan nyata mereka adalah entitas pasif, dalam dunia berorientasi objek, semuanya menjadi entitas aktif dan otonom.
• Lebih baik menggunakan personifikasi untuk menganggap objek pasif sebagai sesuatu yang tertawa, berbicara, dan marah.

Desain Berorientasi Objek

Mengapa Desain Diperlukan?

• Desain adalah tentang menempatkan kode.
• Desain yang baik adalah desain yang dapat sepenuhnya menjalankan fungsi yang dibutuhkan hari ini dan menerima perubahan besok dengan lancar.

Desain Berorientasi Objek

• Kode yang dapat diubah adalah kode yang mudah dipahami.
• Paradigma berorientasi objek membantu kita menulis kode sesuai dengan cara kita melihat dunia.
• Objek adalah entitas otonom yang bertanggung jawab atas data mereka sendiri.
• Desain berorientasi objek yang hebat adalah desain yang mengelola ketergantungan antar objek yang bekerja sama secara tepat.

Sumber

• Objek