konsep object oriented programmer

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 jawaban kepada mereka, sehingga mudah 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 menunjukkan bahwa pembaca tertarik untuk membaca artikel tentang arsitektur, namun kualitasnya tidak sesuai dengan harapan mereka. Artikel ini adalah 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 mengatakan bahwa dua persen terkaya memiliki separuh dari kekayaan dunia. Ini juga mengatakan bahwa satu persen terkaya orang dewasa memiliki 40 persen aset global di tahun 2000. Dan lebih jauh lagi, 10 persen orang dewasa 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, perluasan besar industri perangkat lunak memaksa pengembang menggunakan perpustakaan, layanan, dan kerangka kerja yang telah diterapkan untuk mengembangkan perangkat lunak dalam periode waktu yang lebih singkat. Pengembang baru dilatih untuk menggunakan (saya akan mengatakan lebih sering) komponen perangkat lunak yang sudah dikembangkan untuk menyelesaikan pengembangan lebih cepat. Mereka hanya memasang perpustakaan yang sudah ada dan beberapa cara mengelola untuk mencapai persyaratan. Tapi bagian cerita yang menyedihkan adalah, mereka tidak pernah mendapatkan pelatihan 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 lama tidak paham, karena tidak memiliki pengalaman arsitektural apapun, terus berlanjut, menciptakan vakum arsitek yang baik. Intinya adalah bahwa hanya sebagian kecil pengembang yang tahu bagaimana merancang sistem yang benar-benar berorientasi objek. Solusi untuk masalah ini semakin sulit setiap hari karena sifat agresif industri perangkat lunak tidak mendukung penyesuaian yang mudah terhadap proses yang ada, dan juga materi pengajaran online terkait rumit, atau kurang praktis, atau kadang bahkan salah. Kebanyakan dari mereka menggunakan contoh bentuk, binatang, dan banyak entitas fisik lainnya yang tidak praktis dan tidak relevan untuk mengajarkan konsep arsitektur perangkat lunak. Hanya ada sedikit referensi desain berorientasi bisnis yang bagus. Sayangnya, saya sendiri tidak terkecuali dan merupakan hasil dari sistem yang sama ini. Saya mendapatkan 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 seperti distribusi kekayaan dunia, ini adalah distribusi pengetahuan yang tidak seimbang.

 
2. Latar belakang

Artikel ini dimulai setelah membaca dan mendengar pertanyaan yang dimiliki pengembang baru mengenai dasar-dasar arsitektur perangkat lunak. Ada beberapa artikel bagus 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 baru akan selalu berjuang untuk memahami definisi konsep baru yang tepat, karena selalu merupakan gagasan baru dan karenanya tidak biasa. Orang-orang yang memiliki pengalaman mengerti artinya, tapi orang-orang yang tidak berjuang untuk memahami definisi itu. Ini seperti itu. Majikan menginginkan karyawan yang berpengalaman. Jadi mereka bilang, Anda perlu punya pengalaman untuk mendapatkan pekerjaan. Tapi bagaimana seharusnya seseorang memiliki pengalaman jika 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, seperti yang saya lakukan satu kali. Anda akan merasa sulit untuk memahami kapan dan kapan tidak melakukan sesuatu. Bersiaplah untuk melewati proses yang menyakitkan. Orang lain akan mengkritik Anda, mungkin menertawakan Anda, dan mengatakan bahwa cara Anda merancangnya salah. Dengarkan mereka, dan belajar terus menerus. Dalam proses ini Anda juga harus membaca dan berpikir banyak. Saya harap artikel ini akan memberi Anda awal yang tepat untuk perjalanan panjang itu.
"Pengetahuan tentang 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", tampaknya berlaku di sini, Itu?

 3. Prasyarat

Artikel ini merupakan upaya untuk menyediakan kolam informasi yang akurat bagi pengembang baru mengenai dasar-dasar arsitektur perangkat lunak, dengan fokus pada Object Oriented Programming (OOP). Jika Anda seorang pengembang yang memiliki pengalaman pengembangan minimal tiga tahun dan merasa lapar untuk belajar lebih banyak, melangkah ke tingkat berikutnya untuk menjadi arsitek perangkat lunak, artikel ini adalah untuk Anda.
4. Isi Utama
4.1. Apa itu Arsitektur Perangkat Lunak?

Arsitektur perangkat lunak didefinisikan sebagai aturan, heuristik, dan pola yang mengatur:

     Mempartisi masalah dan sistem yang akan dibangun menjadi potongan-potongan diskrit
     Teknik yang digunakan untuk membuat interface antara potongan-potongan ini
     Teknik yang digunakan untuk mengelola keseluruhan struktur dan aliran
     Teknik yang digunakan untuk antarmuka sistem ke lingkungannya
     Penggunaan pendekatan dan teknik pengembangan dan pengiriman yang tepat.

 4.2. Mengapa Arsitektur Penting?

Tujuan utama arsitektur perangkat lunak adalah untuk menentukan persyaratan non-fungsional suatu sistem dan menentukan lingkungan. Desain rinci diikuti oleh definisi bagaimana menyampaikan perilaku fungsional dalam aturan 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 adalah filosofi desain. Ini singkatan dari Object Oriented Programming. Object-Oriented Programming (OOP) menggunakan seperangkat bahasa pemrograman yang berbeda dari bahasa pemrograman prosedural lama (C, Pascal, dll.). Segala sesuatu di OOP dikelompokkan sebagai "objek" mandiri. Oleh karena itu, Anda mendapatkan reusabilitas dengan menggunakan empat konsep pemrograman berorientasi objek utama.
Agar dapat memahami dengan jelas model orientasi objek, ayo ambil "tangan" Anda sebagai contoh. "Tangan" adalah sebuah kelas. Tubuh Anda memiliki 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 bahu Anda (melalui antarmuka). Jadi bahu adalah antarmuka yang digunakan tubuh Anda untuk berinteraksi dengan tangan Anda. Tangannya adalah kelas yang architected. Tangan sedang digunakan kembali untuk membuat tangan kiri dan tangan kanan dengan sedikit mengubah sifat-sifatnya.

 4.4. Apa itu Obyek?

Benda bisa dianggap sebagai "benda" yang bisa melakukan serangkaian kegiatan terkait. Kumpulan aktivitas yang dilakukan objek mendefinisikan perilaku objek. Misalnya, Hand (objek) bisa mencengkeram sesuatu, atau Student (benda) bisa memberi nama atau alamat mereka.

Dalam istilah OOP murni, sebuah objek adalah sebuah instance dari sebuah kelas.
4.5. Apa itu kelas

 Kelas hanyalah representasi dari jenis objek. Ini adalah cetak biru, atau rencana, atau template, yang menggambarkan detail objek. Kelas adalah cetak biru dari mana objek individual dibuat. Kelas terdiri dari tiga hal: nama, atribut, dan operasi.

 

public class Student
{
}

 Menurut 
contoh yang diberikan di bawah ini dapat kita katakan bahwa objek Siswa,
 bernama objectStudent, telah dibuat 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 mengatakan bahwa sepeda adalah turunan dari kelas objek yang dikenal sebagai sepeda.

Di dunia perangkat lunak, meski mungkin Anda belum menyadarinya, Anda sudah menggunakan kelas. Misalnya, kontrol TextBox, Anda selalu menggunakan, dibuat dari kelas TextBox, yang mendefinisikan kemunculan dan kemampuannya. Setiap kali Anda menyeret kontrol TextBox, Anda sebenarnya membuat instance baru dari kelas TextBox.
4.6. Bagaimana mengidentifikasi dan merancang sebuah Class?

Ini adalah seni; Setiap perancang menggunakan teknik yang berbeda untuk mengidentifikasi kelas. Namun menurut Prinsip Desain Berorientasi Objek, ada lima prinsip yang harus Anda ikuti saat merancang kelas,

 bersambung.....