Pengantar Konsep Pemrograman Berorientasi Obyek (OOP) dan Lainnya
Artikel ini membantu untuk memahami konsep OOP, dengan fokus pada .NET / C #. Ini ditulis dalam bentuk mengajukan pertanyaan dan menulis tanggapan kepada mereka, sehingga gampang dimengerti.
1. Perkenalan
Saya telah memperhatikan peningkatan jumlah artikel yang diterbitkan dalam kategori Arsitektur di CodeProject selama beberapa bulan terakhir. Jumlah pembaca untuk sebagian besar artikel ini juga tinggi, meski peringkat artikelnya tidak. Hal ini menawarkan bahwa pembaca tertarik untuk membaca artikel perihal arsitektur, namun kualitasnya tidak sesuai dengan impian mereka. Artikel ini yaitu upaya konstruktif untuk mengelompokkan / mendefinisikan / menjelaskan semua konsep pengantar arsitektur perangkat lunak bagi pengembang berpengalaman yang ingin mengambil langkah selanjutnya sebagai arsitek sistem.
Suatu hari saya membaca sebuah artikel yang menyampaikan bahwa dua persen terkaya mempunyai separuh dari kekayaan dunia. Ini juga menyampaikan bahwa satu persen terkaya orang remaja mempunyai 40 persen aset global di tahun 2000. Dan lebih jauh lagi, 10 persen orang remaja terkaya menyumbang 85 persen dari total kekayaan dunia. Jadi ada distribusi kekayaan yang tidak seimbang di dunia fisik. Pernahkah Anda memikirkan distribusi pengetahuan yang tidak seimbang di dunia perangkat lunak? Menurut sudut pandang saya, ekspansi besar industri perangkat lunak memaksa pengembang memakai perpustakaan, layanan, dan kerangka kerja yang telah diterapkan untuk menyebarkan perangkat lunak dalam periode waktu yang lebih singkat. Pengembang gres dilatih untuk memakai (saya akan menyampaikan lebih sering) komponen perangkat lunak yang sudah dikembangkan untuk menuntaskan pengembangan lebih cepat. Mereka hanya memasang perpustakaan yang sudah ada dan beberapa cara mengelola untuk mencapai persyaratan. Tapi bab kisah yang menyedihkan adalah, mereka tidak pernah mendapat training untuk mendefinisikan, merancang arsitektur, dan menerapkan komponen semacam itu. Seiring berjalannya waktu beberapa tahun, para pengembang ini menjadi arsitek dan arsitek perangkat lunak. Gelar mereka berubah, namun warisan usang tidak paham, alasannya yaitu tidak mempunyai pengalaman arsitektural apapun, terus berlanjut, membuat vakum arsitek yang baik. Intinya yaitu bahwa hanya sebagian kecil pengembang yang tahu bagaimana merancang sistem yang benar-benar berorientasi objek. Solusi untuk duduk perkara ini semakin sulit setiap hari alasannya yaitu sifat garang industri perangkat lunak tidak mendukung pembiasaan yang gampang terhadap proses yang ada, dan juga bahan pengajaran online terkait rumit, atau kurang praktis, atau kadang bahkan salah. Kebanyakan dari mereka memakai pola bentuk, binatang, dan banyak entitas fisik lainnya yang tidak mudah dan tidak relevan untuk mengajarkan konsep arsitektur perangkat lunak. Hanya ada sedikit acuan desain berorientasi bisnis yang bagus. Sayangnya, saya sendiri tidak terkecuali dan merupakan hasil dari sistem yang sama ini. Saya mendapat pendidikan yang sama dengan yang Anda semua lakukan, dan juga mengacu pada sumber yang sama yang Anda baca.
Kembali ke titik awal, saya perhatikan bahwa ada kesenjangan pengetahuan, meningkat setiap hari, antara arsitek yang tahu bagaimana arsitek sistem dengan benar dan orang lain yang tidak. Orang yang tahu, mengetahuinya dengan benar. Tapi orang-orang yang tidak tahu, tidak tahu apa-apa. Sama menyerupai distribusi kekayaan dunia, ini yaitu distribusi pengetahuan yang tidak seimbang.
2. Latar belakang
Artikel ini dimulai sesudah membaca dan mendengar pertanyaan yang dimiliki pengembang gres mengenai dasar-dasar arsitektur perangkat lunak. Ada beberapa artikel cantik di luar sana, namun pengembang masih berjuang untuk memahami konsep dasarnya, dan yang lebih penting lagi, cara menerapkannya dengan benar.
Seperti yang saya saksikan, pendatang gres akan selalu berjuang untuk memahami definisi konsep gres yang tepat, alasannya yaitu selalu merupakan gagasan gres dan akhirnya tidak biasa. Orang-orang yang mempunyai pengalaman mengerti artinya, tapi orang-orang yang tidak berjuang untuk memahami definisi itu. Ini menyerupai itu. Majikan menginginkan karyawan yang berpengalaman. Jadi mereka bilang, Anda perlu punya pengalaman untuk mendapat pekerjaan. Tapi bagaimana seharusnya seseorang mempunyai pengalaman jikalau tidak ada yang mau memberinya pekerjaan? Seperti pada umumnya, permulaan dengan arsitektur perangkat lunak tidak terkecuali. Ini akan sulit. Ketika Anda mulai merancang sistem pertama Anda, Anda akan mencoba menerapkan semua hal yang Anda ketahui atau pelajari dari mana-mana. Anda akan merasa bahwa sebuah antarmuka perlu didefinisikan untuk setiap kelas, menyerupai yang saya lakukan satu kali. Anda akan merasa sulit untuk memahami kapan dan kapan tidak melaksanakan sesuatu. Bersiaplah untuk melewati proses yang menyakitkan. Orang lain akan mengkritik Anda, mungkin menertawakan Anda, dan menyampaikan bahwa cara Anda merancangnya salah. Dengarkan mereka, dan berguru terus menerus. Dalam proses ini Anda juga harus membaca dan berpikir banyak. Saya harap artikel ini akan memberi Anda awal yang sempurna untuk perjalanan panjang itu.
"Pengetahuan perihal tindakan orang-orang hebat, diperoleh dari pengalaman panjang dalam urusan kontemporer, dan studi abadi yang terus-menerus" - saya membaca ungkapan ini ketika saya membaca buku berjudul "Art of War", sepertinya berlaku di sini, Itu?
3. Prasyarat
Artikel ini merupakan upaya untuk menyediakan kolam isu yang akurat bagi pengembang gres mengenai dasar-dasar arsitektur perangkat lunak, dengan fokus pada Object Oriented Programming (OOP). Jika Anda seorang pengembang yang mempunyai pengalaman pengembangan minimal tiga tahun dan merasa lapar untuk berguru lebih banyak, melangkah ke tingkat berikutnya untuk menjadi arsitek perangkat lunak, artikel ini yaitu untuk Anda.
4. Isi Utama
4.1. Apa itu Arsitektur Perangkat Lunak?
Arsitektur perangkat lunak didefinisikan sebagai aturan, heuristik, dan pola yang mengatur:
Mempartisi duduk perkara dan sistem yang akan dibangun menjadi potongan-potongan diskrit
Teknik yang dipakai untuk membuat interface antara potongan-potongan ini
Teknik yang dipakai untuk mengelola keseluruhan struktur dan aliran
Teknik yang dipakai untuk antarmuka sistem ke lingkungannya
Penggunaan pendekatan dan teknik pengembangan dan pengiriman yang tepat.
4.2. Mengapa Arsitektur Penting?
Tujuan utama arsitektur perangkat lunak yaitu untuk memilih persyaratan non-fungsional suatu sistem dan memilih lingkungan. Desain rinci diikuti oleh definisi bagaimana memberikan sikap fungsional dalam hukum arsitektur. Arsitektur itu penting karena:
Mengontrol kompleksitas
Enforces best practices
Memberikan konsistensi dan keseragaman
Meningkatkan prediktabilitas
Memungkinkan penggunaan ulang.
4.3. Apa itu OOP?
OOP yaitu filosofi desain. Ini kependekan dari Object Oriented Programming. Object-Oriented Programming (OOP) memakai seperangkat bahasa pemrograman yang berbeda dari bahasa pemrograman prosedural usang (C, Pascal, dll.). Segala sesuatu di OOP dikelompokkan sebagai "objek" mandiri. Oleh alasannya yaitu itu, Anda mendapat reusabilitas dengan memakai empat konsep pemrograman berorientasi objek utama.
Agar sanggup memahami dengan terang model orientasi objek, ayo ambil "tangan" Anda sebagai contoh. "Tangan" yaitu sebuah kelas. Tubuh Anda mempunyai dua benda tipe "tangan", diberi nama "tangan kiri" dan "tangan kanan". Fungsi utama mereka dikendalikan atau dikelola oleh satu set sinyal listrik yang dikirim melalui pundak Anda (melalui antarmuka). Jadi pundak yaitu antarmuka yang dipakai badan Anda untuk berinteraksi dengan tangan Anda. Tangannya yaitu kelas yang architected. Tangan sedang dipakai kembali untuk membuat tangan kiri dan ajun dengan sedikit mengubah sifat-sifatnya.
4.4. Apa itu Obyek?
Benda bisa dianggap sebagai "benda" yang bisa melaksanakan serangkaian kegiatan terkait. Kumpulan kegiatan yang dilakukan objek mendefinisikan sikap objek. Misalnya, Hand (objek) bisa mencengkeram sesuatu, atau Student (benda) bisa memberi nama atau alamat mereka.
Dalam istilah OOP murni, sebuah objek yaitu sebuah instance dari sebuah kelas.
4.5. Apa itu kelas
Kelas hanyalah representasi dari jenis objek. Ini yaitu cetak biru, atau rencana, atau template, yang menggambarkan detail objek. Kelas yaitu cetak biru dari mana objek individual dibuat. Kelas terdiri dari tiga hal: nama, atribut, dan operasi.
public class Student { } Menurut pola yang diberikan di bawah ini sanggup kita katakan bahwa objek Siswa, berjulukan objectStudent, telah dibentuk dari kelas Siswa. Di dunia nyata, Anda akan sering menemukan banyak objek individual dengan jenis yang sama. Sebagai contoh, mungkin ada ribuan sepeda lain yang ada, semua model dan model yang sama. Setiap sepeda telah dibangun dari cetak biru yang sama. Dalam istilah berorientasi objek, kita menyampaikan bahwa sepeda yaitu turunan dari kelas objek yang dikenal sebagai sepeda. Di dunia perangkat lunak, meski mungkin Anda belum menyadarinya, Anda sudah memakai kelas. Misalnya, kontrol TextBox, Anda selalu menggunakan, dibentuk dari kelas TextBox, yang mendefinisikan kemunculan dan kemampuannya. Setiap kali Anda menyeret kontrol TextBox, Anda bergotong-royong membuat instance gres dari kelas TextBox. 4.6. Bagaimana mengidentifikasi dan merancang sebuah Class? Ini yaitu seni; Setiap perancang memakai teknik yang berbeda untuk mengidentifikasi kelas. Namun berdasarkan Prinsip Desain Berorientasi Objek, ada lima prinsip yang harus Anda ikuti ketika merancang kelas, bersambung.....
Share this Article