JavaRush /Java Blog /Random-ID /Pemrograman berorientasi objek (terjemahan artikel)
Exidnus
Level 38
Санкт-Петербург

Pemrograman berorientasi objek (terjemahan artikel)

Dipublikasikan di grup Random-ID
Dari penerjemah: Sayangnya, saya tidak memiliki pengalaman yang berarti dalam menerjemahkan dari bahasa Inggris, meskipun saya cukup banyak membaca dalam bahasa Inggris. Namun ternyata membaca dan menerjemahkan adalah dua hal yang berbeda. Sayangnya, saya juga tidak memiliki pengalaman pemrograman yang signifikan (saya baru saja membuat aplikasi web sederhana di Spring MVC dan Hibernate). Oleh karena itu, terjemahannya menjadi jauh lebih buruk daripada yang seharusnya. Saya memberanikan diri untuk sedikit mengoreksi contoh kode yang diberikan dalam artikel, karena contoh tersebut tidak sesuai dengan konvensi penamaan di Java. Mungkin tidak ada gunanya menerjemahkan nama beberapa pola (terjemahan seperti itu tidak memberikan banyak pemahaman), tetapi saya pikir ini adalah kejahatan yang lebih kecil. Perlu disebutkan secara terpisah tentang “kohesi tinggi” sebagai terjemahan dari “kohesi tinggi”. Saya setuju, bukan terjemahan terbaik. Namun “konektivitas yang kuat” adalah “keterhubungan tinggi” (konsep penting lainnya), dan “koherensi” sepertinya tidak cocok di sini. Saya terbuka terhadap kritik dan dengan senang hati akan menerima komentar pada artikel dalam bentuk apapun. Pemrograman berorientasi objek adalah gaya pemrograman di mana suatu program terdiri dari komponen-komponen yang sesuai dengan objek dunia nyata. Setiap objek nyata memiliki beberapa properti (yang mungkin berubah atau tidak seiring waktu) dan perilaku (yang mungkin berubah atau tidak. berubah tergantung pada orang lain).kondisi). Misalnya, pensil adalah benda dunia nyata yang memiliki sifat-sifat berikut:
  • Warnanya merah (tidak berubah seiring waktu).
  • Sekarang panjangnya 10 sentimeter (ini bisa berubah jika pensil diasah).
Dan itu memiliki perilaku berikut:
  • Ini meninggalkan bekas jika digunakan dengan benar.
  • Jejaknya mungkin berbeda tergantung pada tekanan (tergantung faktor eksternal).
  • Panjangnya memendek saat diasah (perilaku permanen).
Seperti dalam contoh ini, objek dunia nyata dapat memiliki banyak properti, namun saat menulis program, kami hanya memperhitungkan properti yang diperlukan. Pemrograman berorientasi objek memiliki kelebihan. Misalnya, mempermudah pembuatan koneksi antara objek dunia nyata dan program dengan cara yang diharapkan. Ini sangat membantu seiring berkembangnya aplikasi dan banyak objek yang berinteraksi satu sama lain. Hal ini membantu dalam mendistribusikan tanggung jawab dalam dunia objektif, memungkinkan Anda untuk fokus memikirkan aplikasi. Fitur penting lainnya yang terkait dengan OOP (Object Oriented Programming) adalah klasifikasi objek. Karena dunia (nyata/virtual) penuh dengan objek, sulit untuk mengontrolnya secara individual. Kita memerlukan cara untuk mengklasifikasikan objek-objek ini yang akan membantu kita mengasosiasikan berbagai objek dan propertinya, seperti pensil hitam. Tidak akan bisa dibedakan (sama?) jika digunakan pada contoh sebelumnya, namun objeknya berbeda. Namun karena keduanya adalah pensil, maka keduanya termasuk dalam kelas "Pensil" yang sama. Sedangkan pulpen yang bentuknya sangat mirip dengan pensil termasuk dalam golongan yang berbeda. Namun, pena dan pensil sama-sama merupakan “Alat Menulis”. Pemrograman berorientasi objek memiliki prinsip-prinsip berikut:
Abstraksi
Abstraksi didefinisikan sebagai kualitas interaksi dengan ide-ide daripada peristiwa atau, dengan kata lain, kebebasan dari kualitas representasional . Hal ini memungkinkan pemrogram untuk fokus pada apa yang diprogram daripada bagaimana memprogramnya . Abstraksi dapat dianggap sebagai kontrak yang melaluinya kami menyediakan fungsionalitas. Detail implementasi mungkin disembunyikan saat menggunakan konsep ini. Contohnya, jika kita membutuhkan sebuah kelas yang menulis, maka kita harus yakin bahwa kelas tersebut mempunyai metode "write". abstract class writer { write (); } Apa yang telah kita lakukan? Kami telah merancang kelas tingkat tinggi yang abstrak, dengan kata lain, ia mengetahui fungsionalitas apa yang kami butuhkan, tetapi cara mengimplementasikannya berada di luar cakupan kelas ini. Ini menawarkan banyak manfaat:
  • Kami mengungkapkan informasi minimum yang diperlukan kepada entitas eksternal, hal ini memungkinkan kami untuk fokus memikirkan program (ini memungkinkan pemikiran terfokus), menghindari kebingungan dan menghindari membuat janji yang tidak diinginkan.
  • Kami memberikan ruang untuk perbaikan di masa depan yang tidak mungkin dilakukan jika rincian implementasi diungkapkan.
Warisan
"Warisan" dalam bahasa Inggris umum berarti "memperoleh dan mewariskan". Kata ini sudah ada dalam budaya kita sejak lama. Nenek moyang memperoleh tanah melalui kerja keras dan mewariskannya kepada anak-anaknya, bahkan alam lebih mengunggulkan warisan. Semua sifat tubuh, seperti tinggi badan, warna kulit/mata/rambut, dll. bergantung pada gen yang kita warisi dari orang tua kita. Warisan mencegah penemuan kembali roda dan mempercepat kemajuan. Itu sama di OOP. Kami membuat kelas induk dengan beberapa properti/perilaku dasar. Semua kelas yang diwarisi dari induk ini akan berisi properti/perilaku yang sama dengan induknya. Namun, kelas yang diwarisi dapat memperoleh lebih banyak properti/perilaku atau mengubah implementasi perilaku tersebut. class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } Dalam contoh di atas, kelas induk (WritingInstrument) memiliki properti “warna” dan perilaku “tulis”. Ketika kelas turunan (pegangan) dideklarasikan, properti "warna" dan perilaku "tulis" tidak perlu dideklarasikan lagi. Mereka hadir di kelas "pegangan" karena warisan. Namun, kelas turunan dapat mendeklarasikan properti/perilaku tambahannya sendiri. Bagaimana kita bisa menggunakan ini dalam praktik? Kami pengembang sangat malas. Kami tidak ingin mencetak sesuatu berulang kali. Keberadaan banyak salinan dari kode yang sama tidak disarankan karena pertimbangan berikut:
  • Semakin sedikit salinan kode, semakin mudah pemeliharaannya.
  • Jika salinan kodenya tidak banyak, maka perubahan di satu tempat akan terlihat di mana-mana.
  • Semakin sedikit kode, semakin sedikit kesalahan.
  • Jika satu kode digunakan di banyak tempat, maka generalisasi tercapai.
  • Kami fokus pada penulisan kode.
  • Kami fokus pada tes.
Warisan di Java dicapai dengan menggunakan kata kunci "extends" dan "implements". class WritingInstrument { } class Pen extends WritingInstrument { }
Polimorfisme
Kata “polimorfisme” berasal dari dua kata: “Poli” , yaitu. “banyak” / “lebih dari satu” “morf” , yaitu “bentuk” Secara harfiah, kata “polimorfisme” mengacu pada kemampuan objek untuk berperilaku berbeda tergantung pada kondisi. Dalam pemrograman, polimorfisme dapat diimplementasikan di beberapa tempat:
  • Kelas
  • Metode
  • Operator
Semua hal di atas mungkin berperilaku berbeda tergantung pada kondisi, mungkin konteks, di mana hal tersebut digunakan. Ini berguna karena klien (pemrogram yang menggunakan perpustakaan Anda) tidak perlu mengetahui banyak seluk-beluk, dan fungsionalitas yang diinginkan diimplementasikan dengan memilih informasi yang diperlukan dari konteksnya. Class WritingObject { wrire() { // пишем, используя стандартные (по дефолту) цвета } } class Pencil extends WritingObject { write() { // пишем, используя серый цвет, написанный текст можно стереть } } class Pen extends WritingObject { write() { // пишем, используя голубой цвет, написанный текст нельзя стереть } } class Main { main() { WritingObject wr = new WritingObject(); wr.write(); // первый вызов WritingObject wr = new Pen(); wr.write(); // второй вызов WritingObject wr2 = new Pencil(); wr2.write(); // третий вызов } } Contoh di atas memiliki implementasi default di WritingObject, yang diperluas/ditimpa oleh kelas turunan pena dan pena. Metode write() dipanggil tiga kali di kelas Utama. Setiap kali implementasi berbeda dipanggil tergantung pada objek mana metode tersebut dipanggil. Dalam hal ini, metode write() memiliki banyak tipe perilaku karena bersifat polimorfik.
Enkapsulasi
Enkapsulasi didefinisikan sebagai pengumpulan data/fungsi terkait dalam satu unit. Ini membantu dalam memfasilitasi akses/modifikasi data. Misalnya, jika kita perlu mencetak semua properti yang dimiliki pengguna tertentu, kita memiliki pilihan berikut: printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) Kita membuat metode yang mengambil semua properti dan mencetaknya satu demi satu. Ketika jumlah elemen dalam daftar bertambah, bidang yang benar tidak dapat lagi diidentifikasi, dan menambahkan/menghapus satu bidang akan mengubah tanda tangan metode. Oleh karena itu, kita perlu mengganti semua pengguna metode ini, meskipun mereka tidak memerlukan kolom yang baru ditambahkan. Untuk membuat kode lebih mudah dibaca dan membuat modifikasi di masa depan lebih mudah, kami merangkum properti di kelas dan mengubahnya menjadi objek kolektif. class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} Objek adalah kumpulan perangkat lunak yang berisi variabel dan metode terkait. Anda dapat merepresentasikan objek dunia nyata menggunakan objek program. Anda dapat membayangkan anjing sungguhan dalam program animasi, atau sepeda sungguhan sebagai objek perangkat lunak di dalam sepeda olahraga. Dalam OOP, kelas adalah templat yang dapat diperluas (templat kode program) untuk membuat objek, menyediakan status awal (variabel) dan perilaku implementasi (fungsi, metode). Akronim SOLID diciptakan oleh Michael Feather untuk “lima prinsip pertama” yang dinamai oleh Robert C. Martin di awal tahun 2000-an. Tujuan dari prinsip-prinsip tersebut, ketika diterapkan bersama-sama, adalah untuk meningkatkan kemungkinan bahwa pemrogram akan menciptakan sistem yang mudah dipelihara dan diperluas. Prinsip SOLID adalah pedoman dalam pengembangan program yang diperlukan untuk menghapus kode "busuk" melalui pemfaktoran ulang, sehingga kode tersebut menjadi mudah dibaca dan diperluas. Ini adalah bagian dari strategi pemrograman yang tangkas dan adaptif.
Prinsip Tanggung Jawab Tunggal
Dalam OOP, prinsip tanggung jawab tunggal menyatakan bahwa setiap kelas harus bertanggung jawab atas satu bagian dari fungsi yang disediakan oleh program, dan tanggung jawab tersebut harus sepenuhnya dirangkum oleh kelas tersebut. Semua fungsinya harus terkait erat dengan tanggung jawab ini.
Prinsip Terbuka/Tertutup
Dalam OOP, prinsip terbuka/tertutup menyatakan bahwa “entitas perangkat lunak (kelas, modul, metode, dll.) harus terbuka untuk perluasan tetapi tertutup untuk perubahan.” Dengan kata lain, entitas harus mengizinkan perilakunya diperluas tanpa mengubah kode sumber.
Prinsip Substitusi Liskov
Substituabilitas adalah prinsip dalam OOP. Dinyatakan bahwa jika S dalam program komputer adalah subtipe dari T, maka objek bertipe T harus sedemikian rupa sehingga dapat digantikan oleh objek bertipe S (yaitu objek bertipe S dapat digantikan oleh objek bertipe T) tanpa mengubah setiap properti yang diperlukan program (akurasi, penyelesaian tugas, dll.).
Prinsip Pemisahan Antarmuka
Prinsip pemisahan antarmuka menyatakan bahwa pemrogram klien tidak boleh dipaksa untuk bergantung pada metode yang tidak digunakannya. Menurut prinsip ini, antarmuka besar perlu dibagi menjadi antarmuka yang lebih kecil dan lebih spesifik sehingga pemrogram klien hanya mengetahui metode yang menarik baginya. Tujuan dari prinsip decoupling antarmuka adalah untuk menjaga sistem tetap terpisah, yang akan memudahkan untuk melakukan refaktorisasi, membuat perubahan, dan penerapan ulang.
Prinsip Pembalikan Ketergantungan
Dalam OOP, prinsip inversi ketergantungan berarti suatu bentuk pemutusan hubungan tertentu antar modul program. Dengan mengikuti prinsip ini, hubungan ketergantungan standar yang dibangun dari modul tingkat tinggi yang membentuk arsitektur aplikasi (pengaturan kebijakan) hingga modul tingkat rendah yang bergantung dibalik (dibalik), sehingga modul tingkat tinggi yang dimodifikasi menjadi independen dari detail implementasi. modul tingkat rendah. Prinsip ini menyatakan:
  • Modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah. Kedua jenis modul harus bergantung pada abstraksi.
  • Abstraksi tidak boleh bergantung pada detail implementasi. Detailnya harus bergantung pada abstraksi.
Prinsip ini membalikkan cara orang berpikir tentang desain berorientasi objek dengan menyatakan bahwa objek tingkat tinggi dan rendah harus bergantung pada abstraksi yang sama.

prinsip GRASP

Pola Perangkat Lunak Penugasan Tanggung Jawab Umum (GRASP) memberikan pedoman untuk menetapkan tanggung jawab ke kelas dan objek dalam desain berorientasi objek.
Pengendali
Pola Pengontrol memberikan tanggung jawab untuk berinteraksi dengan kejadian sistem ke kelas non-GUI yang mewakili keseluruhan sistem atau skenario kasus penggunaan. Pengendali:
  • Ini adalah objek yang tidak berinteraksi langsung dengan pengguna dan bertanggung jawab untuk menerima dan merespons kejadian sistem.
  • Harus digunakan untuk menangani semua kejadian sistem dari satu (atau banyak kasus penggunaan yang saling terkait).
  • Ini adalah objek pertama di belakang GUI yang mengontrol operasi sistem.
  • Dia tidak harus melakukan pekerjaan itu sendiri; tugasnya adalah mengendalikan jalannya peristiwa.
Pencipta
Tugas kelas pencipta adalah membuat dan menginisiasi objek untuk penggunaan selanjutnya. Ia mengetahui parameter inisialisasi, serta objek apa yang akan dibuat. Terkadang kelas pencipta secara aktif membuat objek dan menempatkannya di cache, dan menyediakan satu instance saat diperlukan.
Kohesi Tinggi
Kohesi tinggi merupakan pola evaluatif yang tujuannya adalah untuk menjaga objek-objek sedemikian rupa sehingga ditujukan untuk melakukan satu tugas yang jelas, mudah dikendalikan dan dipahami. High Coupling biasanya digunakan untuk mendukung Low Coupling. Koherensi yang tinggi berarti bahwa tanggung jawab suatu elemen tertentu didefinisikan dengan jelas (sangat terkait dan sangat terfokus). Membagi program menjadi kelas dan subsistem adalah contoh tindakan yang meningkatkan kohesi properti sistem. Sebaliknya, kopling longgar adalah situasi di mana suatu elemen memiliki terlalu banyak tugas yang tidak berhubungan. Elemen yang digabungkan secara longgar cenderung sulit untuk dipahami, dapat digunakan kembali, sulit dipertahankan, dan sulit diubah.
Tipuan
Pola Roundabout mempertahankan penggabungan yang longgar (dan dapat digunakan kembali) antara dua elemen dengan memberikan tanggung jawab atas interaksi di antara keduanya ke objek perantara. Contohnya adalah pengenalan pengontrol untuk memediasi antara data (model) dan tampilannya (tampilan) dalam pola Model-View-Controller (MVC).
Pakar Informasi
Pakar Informasi (juga Pakar atau Prinsip Pakar) adalah prinsip yang digunakan untuk menentukan kepada siapa harus mendelegasikan tanggung jawab. Tanggung jawab mencakup metode, bidang terhitung, dll. Saat menggunakan prinsip ini ketika menugaskan tanggung jawab, pendekatan utamanya adalah urutan tindakan berikut: menganalisis tanggung jawab, mengidentifikasi informasi yang diperlukan untuk memenuhinya, dan akhirnya menetapkan di mana informasi tersebut berada. Penggunaan prinsip Pakar Informasi menghasilkan penugasan tanggung jawab kepada kelas yang memiliki informasi paling banyak untuk melaksanakannya.
Kopling Rendah
Kopling longgar adalah pola evaluasi yang menentukan cara menetapkan tanggung jawab: kopling longgar antar kelas, mengubah satu kelas harus berdampak minimal pada kelas lain, memaksimalkan penggunaan kembali.
Polimorfisme
Menurut polimorfisme, variasi perilaku berdasarkan tipe ditetapkan pada tipe dimana variasi ini terjadi. Hal ini dicapai dengan menggunakan operasi polimorfik.
Variasi yang Dilindungi
Pola Perubahan yang Dilindungi melindungi elemen dari perubahan pada elemen lain (objek, sistem, subsistem) dengan menggabungkan fokus ketidakstabilan dalam antarmuka dan menggunakan polimorfisme untuk membuat implementasi berbeda dari antarmuka tersebut.
Fabrikasi Murni
Konstruksi murni melibatkan kelas yang tidak mewakili konsep dalam domain masalah dan dirancang khusus untuk mencapai kopling longgar, kohesi tinggi, dan oleh karena itu potensi penggunaan kembali maksimum (solusi yang ditawarkan oleh pola Pakar Informasi tidak mencapai hal ini). Kelas seperti ini biasanya disebut “Layanan” dalam desain berbasis domain.

Kritik

Penelitian Potok dkk menunjukkan tidak ada perbedaan yang signifikan antara OOP dan pendekatan prosedural.
Perbandingan kritis OOP dengan teknologi lain, terutama teknologi relasional, sulit dilakukan karena kurangnya definisi OOP yang ketat dan diterima secara luas (Christopher J. Date)
Dibandingkan dengan bahasa lain (dialek LISP, bahasa fungsional, dll.), bahasa OOP tidak memiliki keunggulan unik dan menimbulkan kerumitan yang tidak perlu. (Lawrence Krubner)
Menurut saya pemrograman berorientasi objek secara teknis lemah. Ia mencoba menguraikan dunia menjadi beberapa bagian dalam bentuk antarmuka yang bervariasi dalam satu jenis. Untuk menangani masalah nyata, Anda memerlukan aljabar multisorted - kumpulan antarmuka yang mencakup banyak tipe. Menurut saya pemrograman berorientasi objek secara filosofis tidak sehat. Ini menyatakan bahwa segala sesuatu adalah suatu objek. Sekalipun ini benar, namun tidak terlalu menarik: mengatakan bahwa segala sesuatu adalah sebuah objek berarti tidak mengatakan apa-apa. (Alexander Stepanov)
Popularitas OOP di kalangan perusahaan besar disebabkan oleh "kelompok pemrogram biasa-biasa saja yang besar (dan sering berubah)". Disiplin yang diterapkan oleh OOP mencegah programmer melakukan “terlalu banyak kerugian.” (Paul Graham)
Pemrograman berorientasi objek mengutamakan kata benda. Mengapa mengambil tindakan ekstrem seperti itu dan mengutamakan satu bagian pidato? Mengapa satu konsep lebih diutamakan dibandingkan konsep lainnya? Tidak mungkin OOP tiba-tiba membuat kata kerja menjadi kurang penting bagi pemikiran kita. Anehnya, ini adalah perspektif yang menyimpang. (Steve Yegge)
Rick Hickey, pencipta Clojure, menggambarkan sistem objek sebagai model dunia nyata yang sangat disederhanakan. Dia menekankan ketidakmampuan OOP untuk memodelkan waktu dengan benar, yang menciptakan masalah besar ketika multithreading menjadi hal yang umum dalam program. Eric S. Raymond, seorang pemrogram Unix dan pendukung perangkat lunak sumber terbuka, mengkritik klaim bahwa OOP adalah "Satu Solusi" dan menulis bahwa OOP mendorong program berlapis-lapis, yang menghambat transparansi. Sebagai pendekatan sebaliknya, Raymond memberi contoh Unix dan C.

Tautan

Oleh Margaret Rouse @ WhatIs.com Wikipedia! Warisan ( versi Rusia ) adalah polimorfisme SOLID (Desain Berorientasi Objek) ( versi Rusia ) Prinsip Tanggung Jawab TunggalArgumen yang menentang OOPS ( versi Rusia ) Apa itu OOPS (tanpa hype) Terjemahan: Varygin D.V.
Komentar
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION