Saka penerjemah: Sayange, aku ora duwe pengalaman penting babagan nerjemahake saka basa Inggris, sanajan aku maca cukup akeh ing basa Inggris. Nanging nyatane maca lan nerjemahake iku rong perkara sing beda. Uga, sayangé, aku ora duwe pengalaman program sing signifikan (aku bubar nggawe aplikasi web sing prasaja ing Spring MVC lan Hibernate). Mula, terjemahan kasebut dadi luwih ala tinimbang sing bisa ditindakake. Aku njupuk kamardikan rada mbenerake conto kode diwenehi ing artikel, amarga padha ora tundhuk karo konvensi jeneng ing Jawa. Mbok menawa ora ana gunane nerjemahake jeneng sawetara pola (terjemahan kasebut ora menehi pangerten akeh), nanging aku mikir yen iki minangka ala sing luwih cilik. Prelu disebutake kanthi kapisah babagan "kohesi dhuwur" minangka terjemahan saka "kohesi dhuwur". Aku setuju, dudu terjemahan sing paling apik. Nanging "konektivitas sing kuwat" yaiku "kopling dhuwur" (konsep penting liyane), lan "koherensi" ora cocog ing kene. Aku mbukak kanggo kritik lan matur nuwun bakal nampa komentar ing artikel ing wangun apa wae. Pemrograman berorientasi obyek yaiku gaya pemrograman ing ngendi program digawe saka komponen sing cocog karo obyek ing donya nyata. owah gumantung wong liya).kahanan). Contone, potlot minangka obyek donya nyata sing nduweni sifat ing ngisor iki:
Iku abang (iki ora owah saka wektu).
Saiki dawane 10 sentimeter (bisa diganti yen potlot diasah).
Lan nduweni prilaku ing ngisor iki:
Ninggalake tandha yen digunakake kanthi bener.
Jejak bisa beda-beda gumantung saka tekanan (gumantung faktor eksternal).
Dawane cendhek nalika diasah (prilaku permanen).
Kaya ing conto iki, obyek donya nyata bisa duwe akeh sifat, nanging nalika nulis program kita njupuk menyang akun mung sifat perlu. Pemrograman berorientasi obyek nduweni kaluwihan. Contone, nggampangake kanggo nggawe sambungan antarane obyek donya nyata lan program ing cara samesthine. Iki pancene mbantu nalika aplikasi tuwuh lan akeh obyek sing sesambungan. Iki mbantu nyebarake tanggung jawab ing jagad objektif, supaya sampeyan bisa fokus ing mikir liwat aplikasi kasebut. Fitur penting liyane sing ana gandhengane karo OOP (Object Oriented Programming) yaiku klasifikasi obyek. Wiwit donya (nyata / virtual) kebak obyek, iku angel kanggo ngontrol individu. Kita butuh cara kanggo nggolongake obyek kasebut sing bakal mbantu kita nggandhengake obyek sing beda-beda lan sifate, kayata potlot ireng. Iku bakal ora bisa dibedakake (padha?) Yen digunakake ing conto sadurunge, nanging obyek sing beda. Nanging amarga loro-lorone potlot, padha kalebu kelas "Polot". Dene pulpen, sing meh padha karo potlot, kalebu kelas sing beda. Nanging, pulpen lan potlot minangka "Instrumen Nulis". Pemrograman berorientasi obyek nduweni prinsip ing ngisor iki:
abstraksi
Abstraksi ditetepake minangka kualitas interaksi karo gagasan tinimbang acara utawa, kanthi tembung liya, bebas saka kualitas representasional . Iki ngidini programer kanggo fokus ing apa program tinimbang carane program . Abstraksi bisa dianggep minangka kontrak sing nyedhiyakake fungsionalitas. Rincian implementasine bisa uga didhelikake nalika nggunakake konsep iki. Contone, yen kita butuh kelas sing nulis, mula kita kudu yakin manawa ana metode "tulis". abstract class writer { write (); } Apa sing wis ditindakake? Kita wis ngrancang kelas tingkat dhuwur sing abstrak, ing tembung liyane, ngerti apa fungsi kita kudu, nanging carane ngleksanakake iku metu saka orane katrangan saka kelas iki. Iki menehi akeh keuntungan:
Kita mbukak informasi minimal sing dibutuhake kanggo entitas eksternal, iki ngidini kita fokus ing mikir liwat program (iki mbisakake mikir fokus), ngindhari kebingungan lan ngindhari janji sing ora disengaja.
Kita ninggalake kamar kanggo dandan ing mangsa ngarep sing ora bisa ditindakake yen rincian implementasine dicethakaké.
pusaka
"Pusaka" ing umum Inggris tegese "kanggo ndarbeni lan pass on." Tembung iki wis ana ing budaya kita kanggo dangu. Leluhur angsal tanah liwat karya hard lan liwati marang anak-anake, malah alam ndukung warisan. Kabeh sifat awak, kayata dhuwur, warna kulit / mripat / rambut, lsp. gumantung saka gen sing diwarisake saka wong tuwa. Warisan ngalangi reinventing setir lan nyepetake kemajuan. Iku padha ing OOP. Kita nggawe kelas induk kanthi sawetara sifat / prilaku dhasar. Kabeh kelas sing diwenehi warisan saka wong tuwa iki bakal ngemot sifat / prilaku sing padha karo wong tuwa. Nanging, kelas sing diwarisake bisa entuk sifat / prilaku luwih akeh utawa ngganti implementasine prilaku kasebut. class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } Ing conto ing ndhuwur, kelas induk (WritingInstrument) nduweni sifat "werna" lan prilaku "nulis". Nalika kelas turunan (pegangan) diumumake, properti "werna" lan prilaku "tulis" ora perlu diumumake maneh. Dheweke ana ing kelas "nangani" amarga warisan. Nanging, kelas turunan bisa ngumumake sifat / prilaku tambahan dhewe. Kepiye carane bisa digunakake ing praktik? Kita pangembang banget kesed. Kita ora pengin nyithak soko bola-bali. Anane pirang-pirang salinan kode sing padha ora dianjurake amarga pertimbangan ing ngisor iki:
Sing luwih sithik salinan kode, luwih gampang dijaga.
Yen ora akeh salinan kode kasebut, owah-owahan ing sak panggonan bakal katon ing endi wae.
Kode kurang, kesalahan kurang.
Yen siji kode digunakake ing akeh panggonan, banjur generalisasi wis ngrambah.
Kita fokus ing nulis kode.
Kita fokus ing tes.
Warisan ing Jawa digayuh nggunakake tembung kunci "ngluwihi" lan "nerapake". class WritingInstrument { } class Pen extends WritingInstrument { }
Polimorfisme
Tembung "polimorfisme" asale saka rong tembung: "Poly" , yaiku. "akeh" / "luwih saka siji" "morph" , i.e. "wangun" Secara harfiah, tembung "polimorfisme" nuduhake kemampuan obyek kanggo nindakake kanthi cara sing beda-beda gumantung saka kahanan. Ing pemrograman, polimorfisme bisa ditindakake ing sawetara panggonan:
Kelas
Metode
Operator
Kabeh sing kasebut ing ndhuwur bisa beda-beda gumantung saka kahanan, bisa uga konteks, sing digunakake. Iki migunani amarga klien (programmer sing nggunakake perpustakaan sampeyan) ora perlu ngerti akeh subtleties, lan fungsi sing dikarepake ditindakake kanthi milih informasi sing dibutuhake saka konteks. 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(); // третий вызов } } Conto ing ndhuwur nduweni implementasi standar ing WritingObject, sing ditambahi / ditindhes dening pen lan pen kelas turunan. Cara nulis () diarani kaping telu ing kelas Utama. Saben-saben implementasine beda diarani gumantung obyek sing diarani metode kasebut. Ing kasus iki, nulis () cara wis akeh jinis prilaku amarga iku polymorphic.
Enkapsulasi
Enkapsulasi ditetepake minangka ngumpulake data / fungsi sing gegandhengan ing siji unit. Iki mbantu nggampangake akses / modifikasi data. Contone, yen kita kudu nyetak kabeh properti sing diwenehake pangguna, kita duwe pilihan ing ngisor iki: printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) Kita nggawe metode sing njupuk kabeh properti lan nyithak siji-sijine. Nalika jumlah unsur ing dhaftar mundhak, iku ora bisa maneh kanggo ngenali kolom bener, lan nambah / mbusak siji lapangan bakal ngganti teken cara. Mulane, kita kudu ngganti kabeh panganggo saka cara iki, sanajan padha ora perlu lapangan anyar ditambahaké. Kanggo nggawe kode luwih bisa diwaca lan nggawe modifikasi mangsa luwih gampang, kita encapsulate sifat ing kelas lan nguripake menyang obyek kolektif class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} . Sampeyan bisa makili obyek donya nyata nggunakake obyek program. Sampeyan bisa mbayangno asu nyata ing program animasi, utawa sepeda nyata minangka obyek piranti lunak ing sepeda olahraga. Ing OOP, kelas minangka cithakan extensible (program-code-template) kanggo nggawe obyek, nyedhiyakake kahanan awal (variabel) lan nindakake prilaku (fungsi, metode). Akronim SOLID diciptakake dening Michael Feather kanggo "lima prinsip pisanan" sing dijenengi Robert C. Martin ing awal 2000-an. Sasaran saka prinsip, nalika dileksanakake bebarengan, kanggo nambah kamungkinan sing programmer bakal nggawe sistem sing gampang kanggo njaga lan ngluwihi. Prinsip SOLID minangka pedoman ing pangembangan program sing perlu kanggo mbusak kode "busuk" liwat refactoring, minangka asil kode kasebut kudu gampang diwaca lan bisa diperluas. Iki minangka bagean saka strategi pemrograman sing lincah lan adaptif.
Prinsip Tanggung Jawab Tunggal
Ing OOP, prinsip tanggung jawab siji nyatakake yen saben kelas kudu tanggung jawab kanggo siji bagean saka fungsi sing diwenehake dening program kasebut, lan tanggung jawab kasebut kudu diisi kanthi lengkap dening kelas kasebut. Kabeh fungsine kudu raket karo tanggung jawab iki.
Prinsip Terbuka/Tertutup
Ing OOP, prinsip mbukak / ditutup nyatakake yen "entitas piranti lunak (kelas, modul, metode, lan sapiturute) kudu mbukak kanggo ekstensi nanging ditutup kanggo owah-owahan." Ing tembung liyane, entitas kudu ngidini prilaku ditambahi tanpa ngganti kode sumber.
Prinsip Substitusi Liskov
Substituability minangka prinsip ing OOP. Iki nyatakake yen S ing program komputer minangka subtipe saka T, mula obyek saka jinis T kudu kaya sing bisa diganti dening obyek saka jinis S (yaiku obyek saka jinis S bisa diganti dening obyek saka jinis T) tanpa ngganti. program properti sing dibutuhake (akurasi, ngrampungake tugas, lsp).
Prinsip Segregasi Antarmuka
Prinsip pamisahan antarmuka nyatakake yen programmer klien ora kudu dipeksa gumantung marang metode sing ora digunakake. Miturut prinsip iki, perlu kanggo mbagi antarmuka gedhe dadi sing luwih cilik lan luwih spesifik supaya programmer klien mung ngerti babagan metode sing menarik kanggo dheweke. Tujuan saka prinsip decoupling antarmuka yaiku supaya sistem decoupled, sing bakal luwih gampang kanggo refactor, nggawe owahan, lan redeploy.
Prinsip Inversi Dependensi
Ing OOP, prinsip inversi dependensi tegese wangun tartamtu saka pedhot antarane modul program. Kanthi ngetutake prinsip iki, hubungan dependensi standar sing diadegake saka modul tingkat dhuwur sing mbentuk arsitektur aplikasi (setelan kabijakan) nganti modul tingkat rendah gumantung dibalik (dibalik), saengga modul tingkat dhuwur sing dimodifikasi dadi independen saka rincian implementasine. modul tingkat rendah. Prinsip iki nyatakake:
Modul tingkat dhuwur ngirim ora gumantung ing modul tingkat kurang. Loro-lorone jinis modul kudu gumantung saka abstraksi.
Abstraksi ngirim ora gumantung ing rincian implementasine. Rincian kudu gumantung saka abstraksi.
Prinsip kasebut ngowahi cara wong bisa mikir babagan desain berorientasi obyek kanthi mbantah manawa obyek tingkat dhuwur lan rendah kudu gumantung saka abstraksi sing padha.
prinsip GRASP
Umum Responsibility Assignment Software Patterns (GRASP) menehi pedoman kanggo menehi tanggung jawab kanggo kelas lan obyek ing desain obyek-oriented.
Pengontrol
Pola Controller menehi tanggung jawab kanggo sesambungan karo acara sistem menyang kelas non-GUI sing makili kabeh sistem utawa skenario panggunaan. pengontrol:
Iki minangka obyek sing ora sesambungan langsung karo pangguna lan tanggung jawab kanggo nampa lan nanggapi acara sistem.
Kudu digunakake kanggo nangani kabeh acara sistem saka siji (utawa akeh interrelated) kasus panggunaan.
Iki minangka obyek pisanan ing mburi GUI sing ngontrol operasi sistem.
Dheweke ora kudu nindakake pakaryan dhewe; tugase yaiku ngontrol aliran acara.
pangripta
Tugas kelas pencipta yaiku nggawe lan miwiti obyek kanggo nggunakake sabanjure. Iku ngerti paramèter initialization, uga obyek apa bakal digawe. Kadhangkala kelas pangripta kanthi aktif nggawe obyek lan nyelehake ing cache, lan nyedhiyakake siji conto nalika dibutuhake.
Kohesi Dhuwur
Kohesi dhuwur minangka pola evaluatif, tujuane kanggo ngreksa obyek ing kahanan kaya mengkono sing ditujokake kanggo nindakake tugas sing jelas, gampang dikontrol lan dimangerteni. High Coupling biasane digunakake kanggo ndhukung Low Coupling. Koherensi dhuwur tegese tanggung jawab saka unsur tartamtu ditetepake kanthi jelas (kuat hubungane lan fokus banget). Dibagi program dadi kelas lan subsistem minangka conto tumindak sing nambah kohesi properti sistem. Kopling longgar, ing sisih liya, yaiku kahanan ing ngendi unsur duwe akeh tugas sing ora ana hubungane. Unsur sing digandhengake kanthi longgar cenderung angel dimangerteni, bisa digunakake maneh, angel dijaga, lan angel diganti.
Indidirection
Pola Roundabout njaga kopling longgar (lan bisa digunakake maneh) antarane rong unsur kanthi menehi tanggung jawab kanggo interaksi ing antarane obyek penengah. Conto yaiku introduksi controller kanggo mediasi antarane data (model) lan tampilan (view) ing pola Model-View-Controller (MVC).
Pakar Informasi
Pakar Informasi (uga Ahli utawa Prinsip Pakar) minangka prinsip sing digunakake kanggo nemtokake sapa sing kudu utusan tanggung jawab. Tanggung jawab kalebu metode, kolom sing diwilang, lsp. Nalika nggunakake prinsip iki nalika nemtokake tanggung jawab, pendekatan utama yaiku urutan tumindak ing ngisor iki: nganalisa tanggung jawab, ngenali informasi sing dibutuhake kanggo ngrampungake, lan pungkasane nemtokake lokasi informasi kasebut. Nggunakake prinsip Pakar Informasi ngasilake tanggung jawab marang kelas sing nduweni informasi paling akeh kanggo nglakokake.
Low Coupling
Kopling longgar minangka pola evaluasi sing nemtokake cara nemtokake tanggung jawab: kopling longgar ing antarane kelas, ngganti siji kudu duwe pengaruh minimal ing liyane, ngoptimalake panggunaan maneh.
Polimorfisme
Miturut polimorfisme, variasi prilaku adhedhasar jinis ditugasake kanggo jinis sing variasi iki kedadeyan. Iki digayuh kanthi nggunakake operasi polimorfik.
Variasi sing dilindhungi
Pola Owah-owahan sing Dilindungi nglindhungi unsur saka owah-owahan menyang unsur liyane (obyek, sistem, subsistem) kanthi mbungkus fokus ketidakstabilan ing antarmuka lan nggunakake polimorfisme kanggo nggawe implementasine beda saka antarmuka kasebut.
Fabrikasi Murni
Konstruksi murni nyakup kelas sing ora makili konsep ing domain masalah lan dirancang khusus kanggo entuk kopling sing longgar, kohesi dhuwur, lan potensial nggunakake maneh maksimal (solusi sing ditawakake pola Pakar Informasi ora entuk iki). Kelas kasebut biasane disebut "Layanan" ing desain sing didhukung Domain.
Kritik
Panliten dening Potok dkk. nuduhake ora ana bedane sing signifikan antarane OOP lan pendekatan prosedural.
Perbandingan kritis OOP karo teknologi liyane, utamane teknologi relasional, angel amarga ora ana definisi OOP sing ketat lan ditampa kanthi akeh (Christopher J. Date)
Dibandhingake karo basa liyane (dialek LISP, basa fungsional, lan sapiturute), basa OOP ora duwe kauntungan sing unik lan nyebabake kerumitan sing ora perlu. (Lawrence Krubner)
Aku nemokake pemrograman berorientasi obyek kanthi teknis tipis. Iku nyoba kanggo decompose donya menyang bagean ing syarat-syarat antarmuka sing beda-beda ing siji jinis. Kanggo ngatasi masalah nyata, sampeyan butuh aljabar multisorted - kulawarga antarmuka sing ngluwihi akeh jinis. Aku nemokake pemrograman berorientasi obyek sacara filosofis ora sehat. Iku nyatakake yen kabeh iku obyek. Malah yen iki bener, iku ora menarik banget: ngomong sing kabeh obyek iku ora ngomong apa-apa. (Alexander Stepanov)
Popularitas OOP ing antarane perusahaan gedhe amarga "kelompok programer biasa-biasa wae (lan kerep ganti)." Disiplin sing dileksanakake dening OOP nyegah programmer nindakake "kakehan gawe piala." (Paul Graham)
Pemrograman berorientasi obyek nglebokake tembung-tembung pisanan lan paling penting. Yagene pindhah menyang langkah-langkah sing ekstrem lan sijine salah siji bagéan saka wicara ing pedestal? Yagene konsep siji luwih dhisik tinimbang konsep liyane? Ora mungkin OOP dumadakan nggawe kriya dadi kurang penting kanggo pikiran kita. Iku perspektif miring aneh. (Steve Yegge)
Rick Hickey, pangripta Clojure, nggambarake sistem obyek minangka model sing paling disederhanakake ing donya nyata. Dheweke nandheske OOP ora bisa nggawe model wektu kanthi bener, sing nggawe masalah gedhe nalika multithreading dadi umum ing program. Eric S. Raymond, programmer Unix lan advokat piranti lunak open source, wis kritis marang pratelan yen OOP minangka "The One Solution" lan wis nulis yen OOP nyengkuyung program multi-lapisan, sing ngalangi transparansi. Minangka pendekatan ngelawan, Raymond menehi conto Unix lan C.
GO TO FULL VERSION