Apakah proses sederhana untuk merancang sistem OOP sebelum mengkodekannya?

Setiap kali saya diminta untuk membangun sebuah proyek, saya selalu berhasil membangunnya, bukan sebelumnya merancang rencana atau desain, tetapi setelah pertama menulis kelas yang dibutuhkan, menyempurnakan seluruh proyek, membangun dari bawah ke atas. Sekarang saya tahu ini bukan cara yang tepat untuk membuat perangkat lunak, tetapi tidak mudah bagi saya untuk membungkus kepala saya dengan apa yang disebut Analisis dan Desain Berorientasi Objek. Saya dapat lebih mudah memahami desain prosedural top-down, karena hanya terdiri dari memecah tugas menjadi sub-tugas, hal-hal yang memiliki rekan mereka dalam kode, fungsi. Tetapi Analisis dan Desain Berorientasi Objek Saya tidak dapat dengan mudah memahami, karena saya tidak mengerti bagaimana seseorang dapat mengetahui kelas apa yang mereka butuhkan dan bagaimana mereka akan berinteraksi, kecuali mereka tahu bagaimana mereka akan mengkodekannya.

Untuk sekali kita memperkenalkan konsep kelas dan objek ke dalam proses desain, kita tidak bisa lagi merancang top-down, karena kita tidak lagi memecah masalah kita menjadi hal-hal yang dapat diimplementasikan sebagai prosedur. Sebagai gantinya, sesuai dengan apa yang telah saya baca tentang subjek, kita harus menentukan kelas apa yang dibutuhkan, dan membuat berbagai artefak dalam Unified Modeling Language, yang kemudian dapat kita gunakan ketika kita mengimplementasikan perangkat lunak. Tapi proses desain semacam ini saya tidak mengerti. Karena bagaimana orang tahu kelas mana yang akan mereka butuhkan, dan bagaimana mereka akan berinteraksi, kecuali mereka sudah memahami keseluruhan sistem?

Inilah masalah saya. Saya tidak mengerti bagaimana merancang Sistem Berorientasi Objek, meskipun saya mengerti konsep Pemrograman Berorientasi Objek, dan dapat menggunakan konsep-konsep itu dalam bahasa Pemrograman Berorientasi Objek apa pun yang saya tahu. Oleh karena itu saya membutuhkan seseorang untuk menjelaskan kepada saya proses sederhana apa yang dapat saya gunakan untuk merancang Sistem Berorientasi Objek dengan cara yang masuk akal bagi saya.

Gaya air terjun Top down OOAD tidak memastikan bahwa kode yang Anda tulis berorientasi objek sama sekali. Saya telah melihat pegunungan kode ketat OOAD diproduksi yang membuktikannya. Jika OO membingungkan Anda, jangan mencari bantuan di sini. Kamu tidak akan menemukannya. OO TIDAK mengharuskan Anda mendesain top down.

Jika menyelam ke dalam kelas adalah cara Anda suka kode, biarlah. Biarkan saya memberi tahu Anda sebuah petunjuk. Menunda.

Sungguh menakjubkan betapa mudahnya mendesain kelas dengan menulis kode yang menggunakannya bahkan ketika mereka belum ada. Lupakan prosedur. Lupakan struktur. Cukup buat diri Anda sendiri dengan tingkat abstraksi yang konsisten dan bertahanlah. Jangan menyerah pada godaan dan mencampur detail tambahan ke dalamnya. Apa pun yang membawa Anda keluar dari abstraksi saat ini dapat dilakukan dalam beberapa metode yang mungkin pada beberapa objek lain yang entah bagaimana tahu apa pun yang perlu diketahui. Jangan membangun apa pun yang bisa Anda minta untuk diserahkan kepada Anda.

Belajar menulis seperti itu dan Anda akan menemukan Anda melakukan OO tanpa berusaha keras. Ini memaksa Anda untuk melihat objek Anda dari sudut pandang bagaimana mereka digunakan (antarmuka mereka) dan objek mana yang tahu tentang objek lain. Coba tebak apa dua poin utama diagram UML?

Jika Anda bisa masuk ke mode berpikir itu maka yang tersisa adalah arsitektur. Kita semua masih memikirkannya. Dari MVC hingga arsitektur bersih hingga desain berbasis domain. Pelajari dan mainkan. Gunakan apa yang berhasil. Jika Anda menemukan sesuatu yang 100% andal, kembalilah dan beri tahu saya. Sudah melakukan ini selama beberapa dekade dan saya masih mencari.

Anda mengklaim dapat menggunakan teknik berorientasi objek dalam kode Anda, sehingga dengan itu Anda sudah tahu bagaimana merancang sistem berorientasi objek , saya percaya masalah Anda lebih merupakan masalah kapan , bukan apakah Anda bisa atau tidak. Anda tampak nyaman dengan desain berorientasi objek dalam cara iteratif jangka pendek, bukan cara perencanaan jangka panjang.

Ketika pertama kali mengembangkan suatu proyek mungkin sangat sulit untuk merencanakan dan mendesain, saat itulah pengembangan tangkas lebih disukai daripada pengembangan air terjun , karena ruang lingkup besar rencana air terjun sering tidak akan menangkap semua kompleksitas proyek perangkat lunak.

Anda menyatakan bahwa mengembangkan on-the-fly tanpa "rencana awal" adalah:

"... bukan cara yang tepat untuk membuat perangkat lunak ..."

Jika masalah Anda adalah bahwa rencana awal Anda tidak cukup detail, luangkan sedikit waktu untuk menjelaskan pemikiran pertama Anda. Apa bagian pertama dari program yang Anda rencanakan untuk ditulis? Apa yang dibutuhkan ? Mungkin bahkan tidak memikirkan objek apa yang akan dimulai, alih-alih memikirkan fitur dan rencana apa dari sana.

Jika masalah Anda adalah bahwa Anda tidak percaya diri dalam keterampilan mendokumentasikan / desain / UML Anda , berlatihlah dengan mendokumentasikan proyek yang ada.

Secara pribadi saya akan merekomendasikan untuk tidak khawatir tentang desain Anda yang berorientasi objek sempurna, kebanyakan sistem tidak 100% berorientasi objek. Tujuannya adalah untuk menciptakan pemahaman dan visualisasi sistem yang lebih baik, bukan abstraksi yang sempurna. Orientasi objek bukan peluru perak, itu hanya alat lain di ikat pinggang.

OOAD adalah utopia. Dengan itu saya tidak bermaksud bahwa itu adalah pendekatan terbaik, maksud saya itu tidak pernah benar-benar dapat dicapai dalam pendapat saya yang sederhana. Dalam pengalaman saya, sesuatu selalu berubah, apakah itu persyaratan atau spesifik, atau bahkan konflik ketergantungan yang memaksa Anda untuk mengganti ketergantungan sepenuhnya. Entah karena saya belajar dengan cara ini atau karena itulah yang paling alami bagi saya, ide-ide saya untuk desain datang paling mudah ketika saya menulis kode. Jika saya akan kode dan saya tidak punya ide yang jelas tentang bagaimana saya akan menyusun kode, saya akan membuat titik untuk mendedikasikan waktu untuk benar-benar memahami masalah terlebih dahulu, meskipun lebih sering daripada tidak, saya melihat keharusan untuk kelas dan saya akan membuatnya.

Saran saya adalah bahwa hal terbaik yang dapat Anda lakukan untuk diri Anda sendiri adalah menggunakan kode fasad , menyediakan antarmuka sederhana untuk input dan output, dan berharap input dan output tidak sering berubah. Meskipun demikian, ketahuilah bahwa ini bukan masalah desain, melainkan masalah spesifikasi (perubahan keperluan / operasi / fungsionalitas). Ini akan membuat program Anda agak tahan terhadap masalah yang beresonansi dalam program Anda terhadap mereka yang memanggil program atau bagian kode Anda dan sebaliknya.

Untuk apa yang menyangkut merancang sistem berorientasi objek, sesuatu harus dikatakan untuk mencoba membuat semuanya berorientasi objek padahal seharusnya tidak. Itu adalah kesalahan umum di antara bahasa pemrograman OOP seperti C # dan Java adalah mencoba memperlakukan segala sesuatu sebagai objek, yang sering menghasilkan pembuatan instance tunggal dari kelas untuk melakukan apa yang seharusnya menjadi metode statis yang tidak mengubah keadaan apa pun. Yang mengatakan, tentu saja Anda harus menggunakan desain OOP di mana berlaku, meskipun tidak merasa Anda melakukan kesalahan ketika merasa lebih alami untuk menulis metode statis. Tidak selalu insting yang salah.

Anda harus mempertimbangkan menggunakan kelas ketika Anda menjawab ya untuk salah satu dari pertanyaan berikut:

• Apakah saya memiliki sekelompok informasi yang berkaitan dengan konsep yang sama (yaitu nama depan, nama belakang, alamat)?
• Apakah saya perlu melakukan operasi yang memerlukan beberapa informasi (yaitu calculatePrice(basePrice, quantity, tax))?
• Apakah saya punya yang lain jika dengan blok kode besar melakukan operasi yang sedikit berbeda dengan informasi yang sama atau serupa (yaitu if(type == "cat") { meow(name); } else if (type == "dog") { bark(name); }==> animal.speak())
• Apakah saya memiliki kelas yang sudah ada yang melakukan lebih dari satu tugas tertentu dan tumbuh agak terlalu besar?

Setelah beberapa saat, akan menjadi kebiasaan untuk membuat kelas. Jangan takut menggunakannya jika kode Anda termasuk dalam salah satu kasus di atas. Saya harap itu membantu!

Saya pikir poin yang dibuat oleh Doc Brown dalam komentar layak lebih banyak visibilitas daripada komentar karena dia benar:

" Sekarang saya tahu ini bukan cara yang tepat untuk membuat perangkat lunak " - siapa bilang ini? Sepertinya entah bagaimana Anda jatuh ke dalam perangkap populer percaya "desain adalah sesuatu yang Anda lakukan sebelum pengkodean, mungkin dengan menggambar diagram UML yang mewah". Untuk menyembuhkan Anda dari kesalahpahaman ini, saya sarankan untuk memulai dengan "Code as Design" oleh Jack Reeves. - Doc Brown 21 Juni jam 5:27

@Laiv: "coding" adalah bagian dari apa yang disebut disiplin desain insinyur lainnya. Di gedung rumah, langkah dari desain ke produk akhir dilakukan dengan menggunakan batu bata dan mortar pilling. Dalam pemrograman, langkah ini dilakukan oleh kompiler ketika menerjemahkan desain (= program) menjadi produk akhir (= biner yang dapat dieksekusi). Dan itu bukan kebijaksanaan baru. Esai Reeves berusia 25 tahun. - Doc Brown 21 Juni pukul 6:39

Sentimen yang sama ini juga bergema di tempat lain. Pertimbangkan pembicaraan Glenn Vanderburg tentang "Rekayasa Perangkat Lunak Nyata", dan sampai batas tertentu pembicaraan "Kerajinan, Teknik, dan Esensi Pemrograman" dan "Rekayasa Kerajinan dan Perangkat Lunak". Juga pertimbangkan halaman / diskusi WhatIsSoftwareDesign dan TheSourceCodeIsTheDesign pada wiki C2.

Konsep kode menjadi desain tidak spesifik untuk paradigma apa pun. Ia dapat diaplikasikan secara merata pada berorientasi objek, fungsional, prosedural, logika, atau apa pun. Ide dasarnya sama - desainnya adalah kode sumber itu sendiri. Tindakan konstruksi adalah proses dimana kode sumber (desain) diubah menjadi hal yang dapat digunakan oleh penerjemah atau kompiler.

Dalam sistem yang kompleks, kemungkinan akan ada beberapa desain arsitektur tingkat atas - mengidentifikasi subsistem, komponen, modul, layanan dan mengalokasikan persyaratan kepada mereka sebelum Anda mulai menulis kode. Anda dapat menggunakan UML sebagai cara untuk membuat, mendokumentasikan, dan membantu dalam diskusi seputar desain arsitektur ini. Pertimbangkan gagasan Mode UML yang dibahas Martin Fowler , khususnya UML sebagai Sketsa dan UML sebagai Catatan . Juga pertimbangkan beberapa ide dari Agile Modeling - Pemodelan Arsitektur Awal , Pemodelan Iterasi , dan model Cukup Bagus .

Semua ini berarti bahwa cara yang tepat untuk membangun perangkat lunak bukanlah dengan menyempurnakan keseluruhan proyek. Ini menghabiskan waktu yang cukup untuk memahami persyaratan yang paling kritis (saat ini), mengidentifikasi ketergantungan teknis dan pertukaran di antara persyaratan, dan kemudian mengambil keuntungan dari fakta bahwa perangkat lunak lunak. Sadari juga bahwa biaya untuk mengambil desain Anda dan memproduksi sesuatu sangat rendah (terutama dibandingkan dengan mengambil desain dan memproduksi sesuatu di banyak disiplin ilmu teknik lainnya). Jadi beralih pada kegiatan desain (coding) Anda dan manfaatkan betapa mudah dan murahnya untuk secara progresif membangun atau memodifikasi apa yang telah Anda lakukan.

OOAD adalah tentang mengidentifikasi entitas dan memodelkan objek atau konsep kehidupan nyata ke tingkat abstraksi. Anda akan menganggapnya lebih mudah jika daripada menulis kelas pada antarmuka penulisan yoy pada awalnya, karena Anda belum benar-benar harus mengimplementasikannya, namun kompilasi kode.

OOAD tidak mengesampingkan kemungkinan berpikir dalam sistem sebagai modul besar. Anda masih bisa melakukan itu. Setiap modul ada untuk memuaskan serangkaian cerita pengguna (kasus penggunaan). Kisah pengguna seperti itu membutuhkan kelas yang berkolaborasi untuk memenuhinya.

Salah satu perbedaan utama antara pendekatan prosedural dan OO adalah bahwa biasanya berpikir prosedural memetakan persyaratan untuk menyaring, sedangkan OOD cenderung untuk memikirkan apa yang terjadi di bawah tenda sehingga ujung depan dibuat oleh orang lain atau dengan cara yang tidak OO.

Ada teknik dalam Pemrograman Ekstrim yang disebut Kartu CRC . CRC adalah singkatan dari "tanggung jawab kelas-kolaborator".

Pada dasarnya Anda mengidentifikasi kelas yang jelas dan menetapkan kartu untuk masing-masing. Katakanlah, kelas Invoicememiliki kartu sendiri.

Untuk setiap kelas pemegang kartu, Anda menulis apa yang akan menjadi tanggung jawab kelas itu, misalnya "menghitung total keseluruhan" .

Juga untuk setiap kelas pemegang kartu, Anda menulis kelas apa yang harus diminta oleh kelas untuk memenuhi tanggung jawabnya sendiri. Di sini Anda mungkin menemukan Invoiceperlu kolaborasi InvoiceDetailatau bahkan menemukan bahwa kelas seperti itu diperlukan di tempat pertama.

Anda mungkin menemukan bahwa beberapa tanggung jawab yang Anda pikir milik Invoce, benar-benar milik salah satu kolaboratornya.

Setelah latihan, setiap kartu menjadi kelas, setiap responsabilitas menjadi metode dan setiap hubungan kolaborasi dapat menjadi komposisi, kesepakatan atau panggilan biasa.

Latihan itu dapat (dan harus) dilakukan dalam suatu kelompok, di mana bahkan para pelaku bisnis ikut serta.

Anda dapat mempelajari lebih lanjut tentang teknik ini di tautan ini:

http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

http://www.extremeprogramming.org/rules/crccards.html

Contoh kartu CRC:

Tantangan utama bagi kami, sebagai komunitas praktisi perangkat lunak; lebih khusus praktisi desain berorientasi objek, adalah mewujudkan semua masalah / tugas kita menjadi bagian pemrograman. Baik itu tugas - direpresentasikan sebagai fungsi atau menjadi aktor tugas - diwakili sebagai antarmuka / kelas [mengemudi menuju OOAD]. Seiring kami mengembangkan kebiasaan mendesain perangkat lunak kami, dengan terus mendapatkan pengetahuan tentang berbagai metodologi / kerangka kerja. Sudut pandang kami semakin disempurnakan ke arah pemisahan objek secara jelas dan objek mana yang melakukan fungsi mana.

Sedangkan untuk memecah masalah Anda menjadi sub-masalah dengan kehadiran benda-benda di sekitar, Anda masih dapat dengan mudah melakukan hal itu, karena ANDA memiliki kendali penuh terhadap semua benda yang ingin Anda sajikan. Anda juga memiliki kenyamanan untuk memberikan sifat dan tujuan pada objek dan antarmuka Anda. Yang harus Anda lakukan adalah, memvisualisasikan pernyataan masalah dan memikirkan tujuan / fungsi yang dapat diberikan pada objek yang mana.

Saya akan mencoba menjelaskan lebih jauh dengan bantuan contoh berbagai mobil dan saya akan menyoroti dua cara berbeda untuk memvisualisasikan model objek yang sama.

Ambil contoh dari produsen mobil yang membentang di berbagai kategori mobil: kendaraan komersial, mobil konsumen (sedan, hatchback, station wagon) dll.

Agar pabrikan memiliki pemisahan kategori dan tujuan yang jelas, ada beberapa cara yang dapat digunakan untuk membuat kelas di sana.

1. Berdasarkan kategori (sektor pasar) kendaraan: Kendaraan berat, kendaraan konsumen [sedan, hatchback, station-wagon dll.]

2. Berdasarkan kapasitas mesin & cara mengemudi: 800-1500 CC,> 1500 CC dll.

Pergi dengan cara terbaik di mana pabrikan dapat secara individual memberikan fungsi ke objek milik masing-masing klasifikasi ini, mereka dapat memilih desain objek yang mendasari yang tepat dan membangun model di sana di atasnya.