Bagaimana Anda merancang proyek berorientasi objek? [Tutup]


231

Saya sedang mengerjakan proyek besar (untuk saya) yang akan memiliki banyak kelas dan perlu diperpanjang, tapi saya tidak yakin bagaimana merencanakan program saya dan bagaimana kelas perlu berinteraksi.

Saya mengambil kursus OOD beberapa semester lalu dan belajar banyak darinya; seperti menulis UML, dan menerjemahkan dokumen persyaratan menjadi objek dan kelas. Kami belajar diagram urutan juga, tetapi entah bagaimana saya melewatkan kuliah atau sesuatu, mereka tidak benar-benar bertahan dengan saya.

Dengan proyek-proyek sebelumnya saya sudah mencoba menggunakan metode yang saya pelajari dari kursus tetapi biasanya berakhir dengan kode yang segera setelah saya dapat mengatakan "ya itu terlihat seperti apa yang ada dalam pikiran saya" saya tidak memiliki keinginan untuk menggali melalui kotoran untuk menambahkan fitur baru.

Saya punya salinan Kode Lengkap Steve McConnell yang terus saya dengar luar biasa, di sini dan di tempat lain. Saya membaca bab tentang desain dan sepertinya tidak keluar dengan informasi yang saya cari. Saya tahu dia mengatakan bahwa itu bukan proses potong dan kering, bahwa sebagian besar didasarkan pada heuristik, tetapi saya tampaknya tidak bisa mengambil semua informasinya dan menerapkannya pada proyek saya.

Jadi apa yang Anda lakukan selama fase desain tingkat tinggi (sebelum Anda memulai pemrograman) untuk menentukan kelas apa yang Anda butuhkan (terutama yang tidak didasarkan pada 'objek dunia nyata') dan bagaimana mereka akan berinteraksi satu sama lain ?

Secara khusus saya tertarik pada metode apa yang Anda gunakan? Bagaimana proses yang Anda ikuti yang biasanya menghasilkan desain yang baik dan bersih yang akan mewakili produk akhir?


2
Saya pikir Kode Lengkap cukup membantu dalam hal ini - khususnya bab 5.3 dan 5.4 (yang memiliki beberapa saran lebih konkret), dan seluruh bab 6. Namun, saya belum benar-benar melakukan desain kode untuk proyek besar.
Paul D. Waite

1
Saya dapat merekomendasikan mengikuti kursus tentang desain berorientasi objek di Jawa. Ada yang bagus yang diterbitkan di UDEMY udemy.com/mastering-object-oriented-design-in-java/… . Saya pikir itu pasti dapat membantu Anda. Sumber hebat lainnya adalah mencoba masalah berorientasi objek ATM. Anda dapat google itu.
Suara Kuda

Saya akan merekomendasikan kepada semua orang untuk kembali ke pertanyaan ini ketika Anda benar-benar melakukan perancangan. Ada banyak konten di sini. Dengan cara ini, Anda dapat berlari memori Anda saat Anda melakukan perancangan yang sebenarnya.
Kevin Wheeler

Jawaban:


199

Langkah-langkah yang saya gunakan untuk desain awal (sampai ke diagram kelas), adalah:

  1. Pengumpulan persyaratan. Bicaralah dengan klien dan faktor keluar kasus penggunaan untuk menentukan fungsionalitas apa yang seharusnya dimiliki perangkat lunak.

  2. Tulis narasi kasus penggunaan individual.

  3. Bacalah narasi dan sorot kata benda (orang, tempat, benda), sebagai kandidat kelas dan kata kerja (tindakan), sebagai metode / perilaku.

  4. Buang duplikat nomina dan faktor fungsionalitas umum.

  5. Buat diagram kelas. Jika Anda seorang pengembang Java, NetBeans 6.7 dari Sun memiliki modul UML yang memungkinkan untuk pembuatan diagram serta teknik bolak-balik dan GRATIS. Eclipse (Java IDE open source), juga memiliki kerangka pemodelan, tapi saya tidak punya pengalaman dengannya. Anda mungkin juga ingin mencoba ArgoUML, alat sumber terbuka.

  6. Terapkan prinsip-prinsip OOD untuk mengatur kelas Anda (faktor keluar fungsionalitas umum, susun hierarki, dll.)


6
Ini memang teknik yang berguna, terutama ketika Anda tidak memiliki pegangan nyata pada domain masalah. Namun jarang menghasilkan arsitektur yang optimal.
Tidak

1
Saya dapat merekomendasikan mengikuti kursus tentang desain berorientasi objek di Jawa. Ada yang bagus yang diterbitkan di UDEMY udemy.com/mastering-object-oriented-design-in-java/…. Saya pikir itu pasti dapat membantu Anda. Sumber hebat lainnya adalah mencoba masalah berorientasi objek ATM. Anda dapat google itu.
Suara Kuda

1
Di mana Anda belajar ini? Bisakah Anda memberikan sumbernya?
Kanagavelu Sugumar

68

Menambahkan apa yang dikatakan Scott Davies:

  1. Pastikan Anda tahu semua tentang program Anda sebelum memulai. Apa adalah program anda? Apa yang akan tidak lakukan? Masalah apa yang coba dipecahkannya?

  2. Set kasus penggunaan pertama Anda tidak boleh menjadi cucian daftar semua program yang akhirnya akan dilakukan. Mulailah dengan set kasus penggunaan terkecil yang dapat Anda temukan yang masih menangkap esensi dari tujuan program Anda. Untuk situs web ini, misalnya, kasus penggunaan inti mungkin masuk , ajukan pertanyaan , jawab pertanyaan , dan lihat pertanyaan dan jawaban . Apa-apa tentang reputasi, pemungutan suara, atau wiki komunitas, hanya esensi mentah dari apa yang Anda inginkan.

  3. Ketika Anda menemukan kelas-kelas potensial, jangan pikirkan mereka hanya dalam hal apa kata benda yang mereka wakili, tetapi tanggung jawab apa yang mereka miliki. Saya telah menemukan ini sebagai bantuan terbesar dalam mencari tahu bagaimana kelas berhubungan satu sama lain selama pelaksanaan program. Sangat mudah untuk menemukan hubungan seperti "seekor anjing adalah binatang" atau "anak anjing memiliki satu ibu." Biasanya lebih sulit untuk mengetahui hubungan yang menggambarkan interaksi run-time antara objek. Algoritme program Anda setidaknya sama pentingnya dengan objek Anda, dan mereka jauh lebih mudah untuk dirancang jika Anda telah menjelaskan apa pekerjaan masing-masing kelas.

  4. Setelah Anda memiliki set minimal kasus penggunaan dan objek, mulai coding. Dapatkan sesuatu yang benar-benar berjalan sesegera mungkin, meskipun tidak banyak membantu dan mungkin terlihat seperti sampah. Ini adalah titik awal, dan akan memaksa Anda untuk menjawab pertanyaan yang mungkin Anda sampaikan di atas kertas.

  5. Sekarang kembali dan pilih lebih banyak kasus penggunaan, tulis cara kerjanya, modifikasi model kelas Anda, dan tulis lebih banyak kode. Sama seperti potongan pertama Anda, lakukan sesedikit mungkin sekaligus sambil menambahkan sesuatu yang bermakna. Bilas dan ulangi.

Hanya dua sen saya. Semoga bermanfaat.


19

Ketika saya memiliki kesempatan, saya biasanya menggunakan apa yang saya sebut "aturan iterasi tiga".

Dalam iterasi pertama (atau startup), saya menyusun tata letak umum aplikasi sesuai dengan objek model, algoritma, dan yang diharapkan ( benar-benar diharapkan, tidak mungkindiharapkan) arah masa depan. Saya tidak menulis dokumen desain, tetapi jika saya harus mengoordinasikan banyak orang, sketsa kasar prosedur tentu saja diperlukan, bersama dengan analisis dependensi dan perkiraan perkiraan waktu yang diperlukan. Cobalah untuk menjaga fase ini seminimal mungkin, seperti saya, Anda lebih suka metode yang lebih gesit. Ada kasus di mana fase desain yang kuat diperlukan, khususnya ketika semuanya diketahui dan benar tentang logika program Anda, dan jika Anda berencana untuk memiliki banyak interaksi antara fitur dalam kode Anda. Dalam hal ini, kasus penggunaan atau cerita pengguna menyediakan adalah ide tingkat tinggi yang baik, khususnya untuk aplikasi GUI. Untuk aplikasi baris perintah, dan di perpustakaan tertentu, cobalah untuk menulis "cerita program" di mana Anda membuat kode terhadap perpustakaan yang harus Anda kembangkan dan periksa tampilannya.

Setelah iterasi pertama ini, Anda akan memiliki pemahaman yang lebih baik tentang bagaimana hal-hal berinteraksi, mengeluarkan detail dan titik-titik kasar, memecahkan masalah dengan patch tape yang ditampar. Anda siap memanfaatkan pengalaman ini untuk memperbaiki, membersihkan, memoles, membagi apa yang terlalu besar, menyatukan apa yang terlalu terfragmentasi, menentukan dan menggunakan pola desain, menganalisis hambatan kinerja, dan masalah keamanan nontrivial. Secara umum, semua perubahan ini akan berdampak besar pada tes unit yang Anda tulis, tetapi tidak pada tes fungsional.

Ketika Anda menyelesaikan iterasi kedua ini, Anda akan memiliki permata kecil, teruji dengan baik, didokumentasikan dengan baik, dan dirancang dengan baik. Sekarang Anda memiliki pengalaman dan kode untuk melakukan iterasi ketiga, lanjutkan. Anda akan menambahkan fitur baru dan menggunakan kasing untuk meningkatkan aplikasi Anda. Anda akan menemukan bintik-bintik kasar dan Anda akhirnya akan memasuki iterasi keempat yang analog dengan yang kedua. Bilas dan ulangi.

Ini adalah pendekatan umum saya untuk desain perangkat lunak. Ini mirip dengan desain spiral, dengan iterasi pendek, tiga bulan, dan elemen pengembangan Agile, yang memungkinkan Anda mempelajari masalah dan mengenal perangkat lunak Anda serta bidang aplikasinya. Tentu saja, ini masalah skalabilitas, jadi jika aplikasi ini sangat besar untuk melibatkan ratusan pengembang, hal-hal sedikit lebih kompleks dari ini, tetapi pada akhirnya saya kira idenya selalu sama, bagi et impera .

Jadi, simpulkan:

  1. Di iterasi satu, Anda merasakannya, dan belajar
  2. Dalam iterasi dua, Anda membersihkan produk Anda dan menyiapkannya untuk masa depan
  3. Dalam iterasi tiga, Anda menambahkan fitur baru dan mempelajari lebih lanjut
  4. kebagian 2

16

Sumber paling menarik yang saya ketahui tentang ini adalah Bagian D dari Konstruksi Perangkat Lunak Berorientasi Objek, Edisi ke-2 oleh Bertrand Meyer.

Bagian D: metodologi berorientasi objek: menerapkan metode dengan baik

19: Tentang metodologi, 20: Pola desain: sistem interaktif multi-panel, 21: Studi kasus warisan: "undo" dalam sistem interaktif, 22: Cara menemukan kelas , 23: Prinsip-prinsip desain kelas, 24: Menggunakan warisan dengan baik , 25: Teknik yang berguna, 26: Rasa gaya, 27: Analisis berorientasi objek, 28: Proses pembangunan perangkat lunak, 29: Mengajar metode

Menariknya, bab 22. Cara menemukan kelas tersedia online.


12

Ini sering diulang tetapi sepenuhnya benar - pahami data Anda.

Untuk OOP, kelas Anda harus menggambarkan informasi penting dan bagaimana mereka berinteraksi.

Jika Anda memiliki model mental yang menggambarkan perilaku dan masa pakai data dengan baik, Anda akan mudah menata kelas-kelas Anda.

Ini hanyalah perpanjangan dari: Tahu persis apa yang Anda coba lakukan.


12
Perilaku objek lebih penting daripada data. Ini adalah hasil langsung dari enkapsulasi: inti dari pemrograman berorientasi objek. Eksposur data (dari bahasa seperti C dan Pascal) mengarah ke sistem yang sulit untuk dipertahankan (disempurnakan dan didebug) hanya karena Anda tidak pernah tahu tempat lain apa dalam sistem yang mengubah data. OOP bukan tentang data; OOP adalah tentang perilaku. Ini adalah perbedaan penting.
Dave Jarvis

Ini adalah perbedaan penting, tetapi itu tidak berarti bahwa perilaku lebih penting daripada data.
johnny

Untuk OOD, saya biasanya mulai dari desain Model setelah mengklarifikasi persyaratan, yang memberi saya ide dasar bagaimana entitas harus diatur bagaimana hubungan di antara mereka. Pada saat yang sama, saya memiliki ide dasar tentang operasi yang mungkin terjadi di setiap entitas. Setelah konsep gambar tentang model, kami dapat meninjau persyaratan dan memeriksa apakah kami kehilangan sesuatu. Dan kemudian akan lebih mudah untuk kembali ke level kelas dan level pengontrol.
Joshua

10

Coba gunakan pengembangan yang didorong oleh perilaku. Akan sulit untuk menghentikan kebiasaan lama Anda, tetapi saya telah menemukan bahwa BDD benar-benar pilihan terbaik Anda ketika datang untuk berkembang di dunia nyata.

http://behaviour-driven.org/


1
+1 Menggunakan pengembangan yang didorong oleh uji / perilaku / domain memungkinkan Anda membuat kelas sambil berjalan sehingga Anda akan terhindar dari metodologi air terjun desain muka besar yang bermasalah.
Halvard

8

Masalah dengan proyek besar adalah Anda tidak dapat mengawasi semua interaksi antar komponen. Oleh karena itu penting untuk mengurangi kompleksitas proyek. Diagram Kelas dan Urutan terlalu rinci untuk fase desain ini.

Pertama-tama cobalah untuk berpikir dari tingkat abstraksi yang lebih tinggi. Pikirkan tentang komponen utama dan tanggung jawab mereka (antarmuka mereka ke komponen lain), lihat beberapa pola arsitektur untuk inspirasi (tidak, bukan pola desain, ini terlalu rendah! MVC dan Multi-Tier adalah contoh pola arsitektur). Untuk proyek yang cukup besar, pandangan seperti itu harus memiliki sekitar 3-5 komponen.

Hanya dengan begitu Anda memperbesar komponen tertentu dan mencoba mendesainnya. Sekarang kita berada pada level pola desain dan diagram kelas. Cobalah untuk fokus pada bagian proyek ini, jika Anda merasa perlu menambahkan tanggung jawab ke salah satu komponen lain, cukup tambahkan ke dokumentasi / daftar tugas Anda. Jangan buang waktu untuk berpikir tentang implikasi pada titik ini mereka berubah terlalu cepat, tinjau ketika desain lebih solid.

Anda tidak perlu mendesain sepenuhnya setiap komponen pada saat ini, meskipun mungkin bijaksana untuk memiliki sepotong kode yang mengimplementasikan antarmuka komponen yang tidak diimplementasikan dan menghasilkan respons yang sederhana namun bermanfaat. Dengan cara ini, Anda dapat memulai pengembangan (dan mendesain) satu komponen pada satu waktu dan mengujinya sampai tingkat yang wajar.

Tentu saja, ketika komponen baru selesai, Anda harus menguji bagaimana (dan jika) mereka berintegrasi satu sama lain sebelum melanjutkan.

Singkatnya: Ambil OO dan prinsip penyembunyian informasi, dan naikkan ke level lain!


PS: Melakukan banyak sketsa saat mendesain, itu seperti arsitektur nyata!

PPS: Cobalah untuk mendekati masalah ini dari sudut yang berbeda, pikirkan di luar kotak (meskipun kotak mungkin cara untuk pergi), berdiskusi dengan teman sebaya bisa sangat berguna untuk ini ... dan Anda memiliki sesuatu untuk dibicarakan saat makan siang.


7

Teknik yang saya gunakan dalam proyek nyata dengan kesuksesan yang masuk akal adalah Responsibility Driven Design, yang terinspirasi oleh buku Wirfs-Brock.

Mulailah dengan cerita pengguna tingkat atas, dan dengan rekan kerja, di papan tulis, buat sketsa interaksi tingkat tinggi yang disiratkannya. Ini memberi Anda ide pertama tentang apa modul besar itu; dan satu atau dua permainan kartu CRC tingkat tinggi seperti permainan Anda harus menstabilkan daftar komponen utama, apa yang mereka lakukan dan bagaimana mereka berinteraksi.

Kemudian, jika ada tanggung jawab yang besar atau kompleks, perbaiki modul-modul itu hingga Anda memiliki hal-hal yang kecil dan cukup sederhana untuk menjadi objek, dengan memainkan interaksi di dalam modul untuk setiap operasi utama yang diidentifikasi oleh interaksi tingkat yang lebih tinggi. .

Mengetahui kapan harus berhenti adalah masalah penilaian (yang hanya disertai dengan pengalaman).


+1 untuk papan tulis, hal yang luar biasa: DI memecahkan 80% masalah duduk di depan papan tulis, hanya melihatnya dan berpikir 'apa yang terbaik?'
usoban

7

Pola desain

Pola Desain Kreasi

Singleton - Pastikan hanya satu instance kelas yang dibuat dan Berikan titik akses global ke objek.

Factory (versi Sederhana dari Metode Pabrik) - Membuat objek tanpa memaparkan logika instantiation kepada klien dan Merujuk ke objek yang baru dibuat melalui antarmuka umum.

Metode Pabrik - Menentukan antarmuka untuk membuat objek, tetapi biarkan subclass untuk memutuskan kelas mana yang akan dipakai dan merujuk ke objek yang baru dibuat melalui antarmuka umum.

Abstrak Pabrik - Menawarkan antarmuka untuk membuat keluarga objek terkait, tanpa secara eksplisit menentukan kelas mereka.

Builder - Menentukan instance untuk membuat objek tetapi membiarkan subclass memutuskan kelas mana yang akan dipakai dan Memungkinkan kontrol yang lebih baik atas proses konstruksi.

Prototipe - Menentukan jenis objek yang akan dibuat menggunakan instance prototypical, dan membuat objek baru dengan menyalin prototipe ini.

Pola Desain Perilaku

Chain of Responsibiliy - Ini menghindari melampirkan pengirim permintaan ke penerima, dengan cara ini memberikan objek lain kemungkinan menangani permintaan juga. - Objek menjadi bagian dari rantai dan permintaan dikirim dari satu objek ke yang lain di seluruh rantai sampai salah satu objek akan menanganinya.

Command - Meringkas permintaan dalam suatu objek, Memungkinkan parameterisasi klien dengan permintaan yang berbeda dan Memungkinkan menyimpan permintaan dalam antrian.

Penerjemah - Diberi bahasa, mendefinisikan representasi untuk tata bahasanya bersama dengan juru bahasa yang menggunakan representasi untuk mengartikan kalimat dalam bahasa / Peta domain ke bahasa, bahasa ke tata bahasa, dan tata bahasa ke desain berorientasi objek hirarkis

Iterator - Menyediakan cara untuk mengakses elemen objek agregat secara berurutan tanpa mengekspos representasi yang mendasarinya.

Mediator - Menentukan objek yang merangkum bagaimana satu set objek berinteraksi. Mediator mempromosikan kopling longgar dengan menjaga benda agar tidak saling merujuk secara eksplisit, dan memungkinkan Anda memvariasikan interaksi mereka secara independen.

Pengamat - Menentukan ketergantungan satu-ke-banyak antara objek sehingga ketika satu objek berubah status, semua tanggungannya diberitahukan dan diperbarui secara otomatis.

Strategi - Tetapkan keluarga algoritma, enkapsulasi masing-masing, dan buat mereka dapat dipertukarkan. Strategi memungkinkan algoritma bervariasi secara independen dari klien yang menggunakannya.

Metode Templat - Menentukan kerangka algoritma dalam operasi, menunda beberapa langkah untuk subkelas / Metode Templat memungkinkan subkelas mendefinisikan ulang langkah-langkah tertentu dari suatu algoritma tanpa membiarkan mereka mengubah struktur algoritma.

Pengunjung - Merupakan operasi yang dilakukan pada elemen-elemen struktur objek / Pengunjung memungkinkan Anda menentukan operasi baru tanpa mengubah kelas elemen yang dioperasikannya.

Objek Null - Menyediakan objek sebagai pengganti karena tidak adanya objek dari jenis tertentu. / The Null Object Pattern memberikan perilaku cerdas melakukan apa-apa, menyembunyikan detail dari kolaboratornya.

Pola Desain Struktural

Adaptor - Konversi antarmuka kelas menjadi antarmuka lain yang diharapkan klien. / Adaptor memungkinkan kelas bekerja bersama, yang tidak dapat dilakukan karena antarmuka yang tidak kompatibel.

Bridge - Menyusun objek menjadi struktur pohon untuk mewakili hierarki bagian-keseluruhan. / Composite memungkinkan klien memperlakukan objek individu dan komposisi objek secara seragam.

Komposit - Menyusun objek ke dalam struktur pohon untuk mewakili hierarki bagian-keseluruhan. / Composite memungkinkan klien memperlakukan objek individu dan komposisi objek secara seragam.

Penghias - menambahkan tanggung jawab tambahan secara dinamis ke objek.

Flyweight - penggunaan berbagi untuk mendukung sejumlah besar objek yang memiliki bagian dari keadaan internal mereka yang sama di mana bagian lain dari negara dapat bervariasi.

Memento - menangkap keadaan internal suatu objek tanpa melanggar enkapsulasi dan dengan demikian menyediakan cara untuk mengembalikan objek ke keadaan awal saat dibutuhkan.

Proxy - memberikan "Placeholder" untuk objek untuk mengontrol referensi padanya.


2
Pola bermanfaat bagi sebagian orang. Saya pikir perlu pengalaman yang cukup untuk melihat pola dalam persyaratan. Dan Anda mungkin perlu mendokumentasikannya. Saya cenderung berpikir bahwa pola tidak lebih dari perpustakaan komponen abstrak.
CyberFonic

5

Saya akan merekomendasikan kepada Anda untuk menggunakan BlueJ dan juga ActiveWriter untuk belajar dan juga untuk mengembangkan pemahaman yang baik tentang objek. Buku yang direkomendasikan juga merupakan sumber yang bagus.

Dari Wikipedia :

teks alternatif

BlueJ adalah Lingkungan Pengembangan Terpadu untuk bahasa pemrograman Java, yang dikembangkan terutama untuk tujuan pendidikan, tetapi juga cocok untuk pengembangan perangkat lunak skala kecil.

Selain itu menggunakan UML dan bagi saya itu adalah sumber yang bagus untuk memahami beberapa hal tentang pemodelan objek.

alt teks http://www.ryanknu.com/ryan/bluej.png

ActiveWriter adalah alat untuk memodelkan entitas dan relasi, ia juga menghasilkan kode dan mudah untuk membuat perubahan. Ini akan menghemat waktu Anda dan untuk pengembangan gesit sangat cocok.

teks alternatif
(sumber: altinoren.com )


1
Saya telah menggunakan blue J ... itu pasti berguna tetapi bagaimana itu membantu saya mendesain kelas dan hubungan mereka?
Victor

1
Saya pikir itu membuat saya jelas untuk melihat seluruh gambar tentang bagaimana mengidentifikasi kelas-kelas dan bagaimana menghubungkannya secara visual, dalam langkah pertama saya, saya bereksperimen bagaimana representasi kode objek dan bagaimana memahami berpikir dalam objek. Saya ingat ketika saya mendedikasikan waktu untuk mencari tahu "adalah" dan "memiliki" dan UML sangat membantu. Sejak itu saya menggunakan alat visual ini untuk mendesain objek saya dan ketika saya menemukan ActiveWriter saya sangat senang karena BlueJ tidak memiliki pembuatan kode dan alat ini melakukannya, hanya untuk menegakkan argumen saya, saya pikir secara visual Anda memiliki pendekatan yang lebih luas untuk solusi.
Nelson Miranda

4

Pertama-tama - desain harus berasal dari jiwa Anda. Anda harus merasakannya dengan setiap serat Anda. Saya biasanya berjalan turun selama dua atau tiga bulan sebelum saya mulai melakukan apa pun, hanya berjalan di jalanan (sungguh). Dan berpikir. Berjalan adalah meditasi yang baik, Anda tahu. Sehingga memungkinkan Anda untuk berkonsentrasi dengan baik.

Kedua - gunakan OOP dan kelas hanya di mana hierarki objek alami ada. Jangan 'mengacaukannya' secara artifisial. Jika tidak ada hierarki yang ketat (seperti dalam sebagian besar aplikasi bisnis) - pilih prosedur / fungsional, atau, setidaknya gunakan objek hanya sebagai wadah data dengan pengakses yang terisolasi.

Dan yang terakhir - coba baca ini: Algoritma Berpikir Kreatif


4

Cukup mengutip http://www.fysh.org/~katie/computing/methodologies.txt

Dan pada intinya RUP adalah area kecil di mana Anda harus menggunakan talenta desain OO .... jika Anda tidak memilikinya, ini seperti memiliki metodologi untuk menjalankan 100m.

"Langkah 1: tulis tentang berlari sangat cepat. Langkah 2: Pergi dan gambarkan rencana pacuan kuda. Langkah 3: pergi dan belilah celana pendek lycra yang sangat ketat. Langkah 4: jalankan dengan sangat, sangat, sangat cepat. Langkah 5: lintasi garis terlebih dahulu "

Langkah 4 itulah yang sulit. Tetapi jika Anda memberi banyak penekanan pada 1,2,3 dan 5 mungkin tidak ada yang akan memperhatikan dan kemudian Anda mungkin bisa menghasilkan banyak uang dengan menjual metodologi untuk menjadi atlet yang berpikir ada "rahasia" untuk menjadi 100m. runner over


4

Anda mengajukan pertanyaan yang banyak digunakan penulis untuk menulis buku. Ada sejumlah metodologi dan Anda harus memilih satu yang tampaknya "tercantik" bagi Anda.
Saya dapat merekomendasikan buku "Desain Domain Didorong" oleh Eric Evans. Juga, periksa situs dddcommunity.org .


3

Saya pikir jawabannya di sini harus sangat berbeda tergantung pada pengalaman dunia nyata dari pria yang bertanya.

Jika Anda hanya memiliki satu atau dua tahun pengalaman kerja, maka Anda harus pergi ke titik itu adalah: bagaimana Anda sampai ke titik Anda benar-benar tahu data Anda dan mengerti persis apa yang Anda coba lakukan?

Ya, jika Anda telah bekerja di dunia nyata 5+ tahun maka Anda akan memilih di antara banyak model atau teknik proses pengembangan perangkat lunak.

Tetapi Anda tidak mendapatkan pengalaman dengan membaca buku saja. Anda harus belajar dengan bekerja dalam kelompok yang baik di bawah kepemimpinan yang baik.

Jika itu tidak mungkin maka Anda harus melakukannya sendiri. Mulailah mengulangi dengan mengkode kode yang mungkin sangat tidak menyenangkan, mempelajari kesalahan Anda, membuang semuanya, mengkode yang lebih baik, dan seterusnya.

Anda akan belajar banyak tentang basis kode Anda. Alat adalah alat, mereka tidak akan mengajarkan apa pun kepada Anda.


3

Jika Anda memiliki keahlian domain pada proyek Anda akan bekerja seperti katakanlah perbankan. Sangat mudah untuk menyusun objek Anda dan Anda tahu bagaimana peningkatan itu terjadi setiap hari.

Jika Anda tidak memiliki keahlian itu bekerja dengan seseorang yang memiliki keahlian itu dan mengubah ide-ide itu menjadi detail teknis.

Jika Anda bingung bagaimana cara menyusun desain proyek Anda. BUTA ikuti buku "programmer pragmatis". Saya berada dalam situasi yang sama sebelumnya, cobalah membaca satu bab dari buku itu. Anda akan melihat perbedaannya, Ini akan mengubah cara Anda berpikir sebagai pengembang perangkat lunak.


2
  1. belajar & menguasai Pola Desain.
  2. Selanjutnya, pelajari tentang Desain Berbasis Domain
  3. Setelah itu, pelajari persyaratan pengumpulan

Saya mengambil kursus OOD beberapa semester lalu dan belajar banyak darinya; seperti menulis UML, dan menerjemahkan dokumen persyaratan menjadi objek dan kelas. Kami belajar diagram urutan juga, tetapi entah bagaimana saya melewatkan kuliah atau sesuatu, mereka tidak benar-benar bertahan dengan saya.

  1. Anda tahu tentang langkah 3. Anda harus menguasainya. Maksud saya, melalui banyak latihan untuk membuatnya menjadi sifat kedua Anda. Itu karena metode yang Anda pelajari, bertentangan dengan cara yang dulu kami miliki. Jadi, Anda harus benar-benar menguasainya. Jika tidak, Anda akan selalu kembali ke cara awal Anda melakukan sesuatu. Ini seperti Test Driven Process, di mana banyak pengembang java menyerah setelah beberapa kali mencoba. Kecuali mereka sepenuhnya menguasainya, kalau tidak itu hanya beban bagi mereka

  2. Menulis kasus penggunaan, terutama untuk kursus alternatif. Kursus alternatif menempati lebih dari 50% dari waktu pengembangan kami. Biasanya ketika PM Anda memberi Anda tugas, misalnya, membuat sistem login, ia akan berpikir itu langsung, Anda dapat mengambil 1 hari untuk menyelesaikannya. Tapi dia tidak pernah memperhitungkan bahwa Anda perlu mempertimbangkan, 1. bagaimana jika pengguna memasukkan kata sandi yang salah, 2. bagaimana jika pengguna memasukkan kata sandi yang salah sebanyak 3 kali, 3. bagaimana jika pengguna tidak mengetikkan nama pengguna dan lain-lain. Anda perlu mencantumkannya, dan menunjukkannya kepada PM Anda, minta dia untuk menjadwal ulang batas waktu.


2

Saya takut ini bukan jawaban yang suka didengar orang . Bagaimanapun, izinkan saya menyatakan pendapat saya.

OOP harus dipandang sebagai salah satu paradigma, bukan paradigma superior. OOP baik untuk memecahkan masalah tertentu, seperti mengembangkan perpustakaan GUI. Ini juga cocok dengan gaya pengembangan perangkat lunak yang biasanya diikuti oleh perusahaan perangkat lunak besar - tim elit desainer atau arsitek meletakkan desain perangkat lunak dalam diagram UML atau media serupa lainnya dan tim pengembang yang kurang tercerahkan.terjemahkan desain itu ke dalam kode sumber. OOP menawarkan sedikit manfaat jika Anda bekerja sendiri atau dengan tim kecil programmer yang sangat berbakat. Kemudian, lebih baik menggunakan bahasa yang mendukung banyak paradigma dan akan membantu Anda menghasilkan prototipe dengan cepat. Python, Ruby, Lisp / Skema dll adalah pilihan yang baik. Prototipe adalah desain Anda. Maka Anda memperbaiki itu. Gunakan paradigma yang terbaik untuk menyelesaikan masalah yang ada. Jika perlu, optimalkan hot spot dengan ekstensi yang ditulis dalam C atau bahasa sistem lainnya. Dengan menggunakan salah satu dari bahasa ini, Anda juga mendapatkan ekstensibilitasgratis, tidak hanya di tingkat programmer tetapi juga di tingkat pengguna. Bahasa seperti Lisp dapat menghasilkan dan mengeksekusi kode secara dinamis, yang berarti pengguna Anda dapat memperpanjang aplikasi dengan menulis cuplikan kode kecil, dalam bahasa yang perangkat lunaknya sendiri dikodekan! Atau jika Anda memilih untuk menulis program dalam C atau C ++, pertimbangkan untuk menyematkan juru bahasa untuk bahasa kecil seperti Lua. Paparkan fungsionalitas sebagai plugin yang ditulis dalam bahasa itu.

Saya pikir itu, sebagian besar waktu OOP dan OOD membuat perangkat lunak yang menjadi korban dari desain yang berlebihan.

Sebagai rangkuman, cara saya yang disukai untuk menulis perangkat lunak adalah:

  1. Gunakan bahasa yang dinamis.
  2. Tulis desain (prototipe) dalam bahasa itu sendiri.
  3. Jika perlu, optimalkan area tertentu menggunakan C / C ++.
  4. Berikan ekstensibilitas dengan cara penerjemah bahasa implementasi itu sendiri.

Fitur terakhir memungkinkan perangkat lunak untuk dengan mudah beradaptasi dengan persyaratan pengguna tertentu (termasuk saya!).


Hal ini tidak menyarankan tentang bagaimana merancang
Nama

2
Saya menggunakan pendekatan serupa. Untuk menghindari kewalahan oleh kerumitan, mulailah dengan tampilan helikopter. Saya suka sketsa dengan 8-20 fungsi. Jika saya mulai mendapatkan lebih banyak maka saya melihat bagaimana cara mempartisi ke dalam sub-sistem. Setelah saya memiliki tampilan tingkat tinggi, saya akan mendekomposisi setiap fungsi menjadi 8-20 sub-fungsi, dll. Dengan melihat apa yang dimanipulasi fungsi-fungsi tersebut, saya mendapatkan kelas tingkat atas. Saat itulah saya mulai meletakkan sistem kerangka dengan Python, alias kode semu yang dapat dieksekusi. Itu bersama dengan blok komentar adalah 'spesifikasi yang dapat dieksekusi' saya yang kemudian semakin disempurnakan.
CyberFonic

2

Saya menggunakan Test-Driven Design (TDD). Menulis tes terlebih dahulu sebenarnya membantu mengarahkan Anda ke desain yang bersih dan benar. Lihat http://en.wikipedia.org/wiki/Test-driven_development .


2
TDD membantu memvisualisasikan sistem Anda pada awalnya sebagai kotak hitam dengan input dan output sampelnya. Tapi itu tidak membantu Anda untuk datang dengan desain sistem. Maksud saya untuk tes unit, pertama-tama Anda harus datang dengan antarmuka kelas untuk menguji
Vicente Bolea

2

Pelajari pola desain . Ini adalah revolusi pribadi saya selama dua tahun terakhir mengenai OOP. Dapatkan buku. Saya akan merekomendasikan Anda yang ini:

Pola Desain Kepala Pertama

Itu di Jawa tetapi bisa diperluas ke bahasa apa pun.


1

Jujur, langkah yang baik akan kembali dan melihat diagram alur dan diagram urutan. Ada banyak situs bagus yang menunjukkan cara melakukannya. Saya merasa itu sangat berharga ketika melihat bagaimana saya ingin memecah sebuah program menjadi kelas-kelas karena saya tahu persis apa yang perlu diinput, dihitung, dan dikeluarkan oleh program dan setiap langkah dapat dipecah menjadi satu bagian dari program.


1
Saya suka diagram alur ketika saya mengalami masalah. Kadang-kadang membantu saya memikirkan masalah dengan cara yang berbeda.
user133018

Alih-alih atau juga bagan alur, "Data Flow Diagram" (DFD) jauh lebih tinggi: mereka lebih seperti diagram penempatan UML, dan cocok untuk mendapatkan wawasan tentang fungsionalitas sistem (yaitu input data sistem dan output data, penyimpanan data internal dan eksternal, dan pemrosesan data), dan arsitektur. Flow-chart (IMHO) lebih dekat dalam cakupan untuk memodelkan fungsi tunggal dengan pernyataan if-then-else.
ChrisW

Ya, saya menggunakan sebagian besar waktu biasanya diagram alir terutama untuk ketika saya mencoba untuk mencari tahu masalah tertentu.
user133018

Menggunakan swimlanes memecahkan banyak masalah dengan diagram alur. Saya telah menemukan bahwa menggunakan satu diagram urutan per skenario berfungsi paling baik. Setiap skenario mencakup satu jalur tertentu melalui pohon keputusan sehingga tidak ada IF dalam aliran. Jika Anda ingin memiliki diagram tunggal dengan semua alur, Anda harus memasukkan poin keputusan tetapi akan berantakan dengan cepat, terutama jika Anda ingin memasukkan penugasan tanggung jawab.
Kelly S. Prancis


1

Salah satu teknik yang berguna adalah menghubungkan deskripsi masalah unik Anda dengan sesuatu yang dapat Anda temukan di dunia nyata. Misalnya, Anda memodelkan sistem perawatan kesehatan yang kompleks yang akan membuat dunia terguncang. Apakah ada contoh yang bisa Anda panggil untuk memodelkan ini?

Memang. Amati bagaimana apotek samping akan beroperasi, atau ruang dokter.

Bawa masalah domain Anda ke sesuatu yang dapat dimengerti oleh Anda; sesuatu yang bisa Anda hubungkan.

Kemudian begitu "pemain" dalam domain mulai tampak jelas, dan Anda mulai memodelkan kode Anda, memilih pendekatan pemodelan "penyedia-konsumen" yaitu kode Anda adalah "penyedia" model, dan Anda adalah "konsumen" ".

Berkaitan dengan domain dan memahaminya di tingkat tinggi adalah bagian penting dari desain apa pun.


1

Selama petualangan saya merancang struktur kelas, saya perhatikan bahwa sangat membantu untuk memulai dengan menulis beberapa kode semu. Itu berarti: Saya mulai dengan "menulis" beberapa fragmen umum kode aplikasi pada level tertinggi, bermain dengannya, dan menemukan elemen-elemen yang muncul - sebenarnya, elemen yang saya - sebagai programmer - ingin gunakan. Ini adalah titik awal yang sangat baik untuk merancang struktur umum modul dan interaksinya. Setelah beberapa iterasi seluruh struktur mulai terlihat lebih seperti sistem kelas penuh. Ini adalah cara yang sangat fleksibel untuk merancang bagian-bagian kode. Anda dapat menyebutnya desain berorientasi programer.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.